* [Qemu-devel] SIGSEGV on Windows with KQEMU enabled
@ 2009-03-07 0:39 Consul
2009-03-07 2:51 ` Anthony Liguori
0 siblings, 1 reply; 11+ messages in thread
From: Consul @ 2009-03-07 0:39 UTC (permalink / raw)
To: qemu-devel
First, the current SVN (6731) does not compile on Windows due to missing asprintf.
This hack lets me compile the app, but running a Windows XP image gives SIGSEGV during the boot.
As Robert mentioned in another thread it might be a binutils bug after all - I'm using 2.19 -
but it might be as well a kqemu bug. The crash happens in kqemu.c. See the trace below.
Note: SIGSEGV does not happens with -no-kqemu
===================================================================
--- vnc.c (revision 6731)
+++ vnc.c (working copy)
@@ -62,10 +62,14 @@
err, gai_strerror(err));
return NULL;
}
-
+#ifndef _WIN32
if (asprintf(&addr, format, host, serv) < 0)
return NULL;
-
+#else
+ if (!(addr = malloc(512)))
+ return NULL;
+ sprintf(addr, format, host, serv);
+#endif
return addr;
}
===================================================================
Starting program: c:\test\qemu/i386-softmmu/qemu.exe -L c:\qemu-dist -hda c:\qemu-img\wxp.q2 -fda c:\qemu-img\boot.bin -boot c -localtime -m 512 -soundhw es1370 -net nic,model=rtl8139 -net tap,ifname=TAP0 -kernel-kqemu
[New thread 3488.0xd48]
[New thread 3488.0xde0]
[New thread 3488.0xcb0]
[New thread 3488.0xfb0]
[New thread 3488.0xba8]
[New thread 3488.0x3bc]
[New thread 3488.0x484]
Program received signal SIGSEGV, Segmentation fault.
kqemu_cpu_exec (env=0x2ef9eff8) at c:/test/qemu/kqemu.c:475
475 asm volatile ("fxrstor %0" : "=m" (*fp));
(gdb) bt
#0 kqemu_cpu_exec (env=0x2ef9eff8) at c:/test/qemu/kqemu.c:475
#1 0x004ac1e6 in cpu_x86_exec (env1=0x806ef000)
at c:/test/qemu/cpu-exec.c:317
#2 0x00407f38 in qemu_get_timedate (tm=<value optimized out>, offset=1)
at c:/test/qemu/vl.c:1816
#3 0x00000000 in ?? ()
(gdb)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] SIGSEGV on Windows with KQEMU enabled
2009-03-07 0:39 [Qemu-devel] SIGSEGV on Windows with KQEMU enabled Consul
@ 2009-03-07 2:51 ` Anthony Liguori
2009-03-13 1:28 ` [Qemu-devel] " Consul
0 siblings, 1 reply; 11+ messages in thread
From: Anthony Liguori @ 2009-03-07 2:51 UTC (permalink / raw)
To: qemu-devel
Consul wrote:
> First, the current SVN (6731) does not compile on Windows due to
> missing asprintf.
With what toolkit? It builds for me.
Regards,
Anthony Liguori
> This hack lets me compile the app, but running a Windows XP image
> gives SIGSEGV during the boot.
> As Robert mentioned in another thread it might be a binutils bug after
> all - I'm using 2.19 -
> but it might be as well a kqemu bug. The crash happens in kqemu.c. See
> the trace below.
>
> Note: SIGSEGV does not happens with -no-kqemu
>
> ===================================================================
> --- vnc.c (revision 6731)
> +++ vnc.c (working copy)
> @@ -62,10 +62,14 @@
> err, gai_strerror(err));
> return NULL;
> }
> -
> +#ifndef _WIN32
> if (asprintf(&addr, format, host, serv) < 0)
> return NULL;
> -
> +#else
> + if (!(addr = malloc(512)))
> + return NULL;
> + sprintf(addr, format, host, serv);
> +#endif
> return addr;
> }
>
> ===================================================================
>
> Starting program: c:\test\qemu/i386-softmmu/qemu.exe -L c:\qemu-dist
> -hda c:\qemu-img\wxp.q2 -fda c:\qemu-img\boot.bin -boot c -localtime
> -m 512 -soundhw es1370 -net nic,model=rtl8139 -net tap,ifname=TAP0
> -kernel-kqemu
> [New thread 3488.0xd48]
> [New thread 3488.0xde0]
> [New thread 3488.0xcb0]
> [New thread 3488.0xfb0]
> [New thread 3488.0xba8]
> [New thread 3488.0x3bc]
> [New thread 3488.0x484]
>
> Program received signal SIGSEGV, Segmentation fault.
> kqemu_cpu_exec (env=0x2ef9eff8) at c:/test/qemu/kqemu.c:475
> 475 asm volatile ("fxrstor %0" : "=m" (*fp));
> (gdb) bt
> #0 kqemu_cpu_exec (env=0x2ef9eff8) at c:/test/qemu/kqemu.c:475
> #1 0x004ac1e6 in cpu_x86_exec (env1=0x806ef000)
> at c:/test/qemu/cpu-exec.c:317
> #2 0x00407f38 in qemu_get_timedate (tm=<value optimized out>, offset=1)
> at c:/test/qemu/vl.c:1816
> #3 0x00000000 in ?? ()
> (gdb)
>
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-07 2:51 ` Anthony Liguori
@ 2009-03-13 1:28 ` Consul
2009-03-13 10:37 ` Johannes Schindelin
0 siblings, 1 reply; 11+ messages in thread
From: Consul @ 2009-03-13 1:28 UTC (permalink / raw)
To: qemu-devel
Anthony Liguori wrote:
> Consul wrote:
>> First, the current SVN (6731) does not compile on Windows due to
>> missing asprintf.
>
> With what toolkit? It builds for me.
>
The SIGSEGV has been introduced in rev 6712 (monitor.c).
The current version (6826 with the asprintf patch) is still affected.
It only happens if:
1. compiled with GCC4
gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502
ln (GNU coreutils) 5.97
2. kqemu is enabled (either user or kernel modes).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-13 1:28 ` [Qemu-devel] " Consul
@ 2009-03-13 10:37 ` Johannes Schindelin
2009-03-13 17:33 ` Consul
0 siblings, 1 reply; 11+ messages in thread
From: Johannes Schindelin @ 2009-03-13 10:37 UTC (permalink / raw)
To: Consul; +Cc: qemu-devel
Hi,
On Thu, 12 Mar 2009, Consul wrote:
> Anthony Liguori wrote:
> > Consul wrote:
> > > First, the current SVN (6731) does not compile on Windows due to
> > > missing asprintf.
> >
> > With what toolkit? It builds for me.
>
> The SIGSEGV has been introduced in rev 6712 (monitor.c). The current
> version (6826 with the asprintf patch) is still affected. It only
> happens if:
>
> 1. compiled with GCC4
>
> gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502
> ln (GNU coreutils) 5.97
>
> 2. kqemu is enabled (either user or kernel modes).
Funnily enough, I have a similar issue in another project. Could you try
compiling with --std=c99?
Alternatively, you might want to try to
#define snprintf __mingw_snprintf
#define vsnprintf __mingw_vsnprintf
in a central place.
Explanation: M$' C runtime is not C99 compliant. It interprets %llu to
mean "unsigned long", not "unsigned long long". As a consequence, the
bitwidths of the parameters are interpreted wrong, so that pointers after
that parameter point anywhere but the correct address.
As far as I can tell, TDM's GCC works around most of the issue, but forgot
snprintf and vsnprintf.
You might also be interested in this:
https://sourceforge.net/tracker/index.php?func=detail&aid=2671742&group_id=200665&atid=974439
Hth,
Dscho
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-13 10:37 ` Johannes Schindelin
@ 2009-03-13 17:33 ` Consul
2009-03-14 12:16 ` Johannes Schindelin
0 siblings, 1 reply; 11+ messages in thread
From: Consul @ 2009-03-13 17:33 UTC (permalink / raw)
To: qemu-devel
Johannes Schindelin wrote:
> compiling with --std=c99?
with -std=c99 it does not even compile
>
> Alternatively, you might want to try to
>
> #define snprintf __mingw_snprintf
> #define vsnprintf __mingw_vsnprintf
>
These give linker undefined symbol errors.
But really funny think is the change that triggers the bug is precisely this:
-Monitor *cur_mon;
+Monitor *cur_mon = NULL;
Obviously, kqemu is happier having garbage in the cur_mon than NULL
> in a central place.
>
> Explanation: M$' C runtime is not C99 compliant. It interprets %llu to
> mean "unsigned long", not "unsigned long long". As a consequence, the
> bitwidths of the parameters are interpreted wrong, so that pointers after
> that parameter point anywhere but the correct address.
>
> As far as I can tell, TDM's GCC works around most of the issue, but forgot
> snprintf and vsnprintf.
>
> You might also be interested in this:
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2671742&group_id=200665&atid=974439
>
> Hth,
> Dscho
>
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-13 17:33 ` Consul
@ 2009-03-14 12:16 ` Johannes Schindelin
2009-03-14 12:36 ` Andreas Färber
2009-03-15 0:42 ` Paul Brook
0 siblings, 2 replies; 11+ messages in thread
From: Johannes Schindelin @ 2009-03-14 12:16 UTC (permalink / raw)
To: Consul; +Cc: qemu-devel
Hi,
On Fri, 13 Mar 2009, Consul wrote:
> Johannes Schindelin wrote:
>
> > compiling with --std=c99?
>
> with -std=c99 it does not even compile
... error message?
> > Alternatively, you might want to try to
> >
> > #define snprintf __mingw_snprintf
> > #define vsnprintf __mingw_vsnprintf
> >
>
> These give linker undefined symbol errors.
... error message?
And further: do you use the TDM GCC4?
> But really funny think is the change that triggers the bug is precisely this:
> -Monitor *cur_mon;
> +Monitor *cur_mon = NULL;
>
> Obviously, kqemu is happier having garbage in the cur_mon than NULL
I rather expect that to _hide_ the bug. The "garbage" might be a
left-over from the heap.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-14 12:16 ` Johannes Schindelin
@ 2009-03-14 12:36 ` Andreas Färber
2009-03-15 0:42 ` Paul Brook
1 sibling, 0 replies; 11+ messages in thread
From: Andreas Färber @ 2009-03-14 12:36 UTC (permalink / raw)
To: qemu-devel; +Cc: Consul
Hi,
Am 14.03.2009 um 13:16 schrieb Johannes Schindelin:
> On Fri, 13 Mar 2009, Consul wrote:
>
>> Johannes Schindelin wrote:
>>
>>> compiling with --std=c99?
>>
>> with -std=c99 it does not even compile
>
> ... error message?
That didn't work on Solaris either (cf. list archive).
We needed -std=gnu99 there.
Andreas
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-14 12:16 ` Johannes Schindelin
2009-03-14 12:36 ` Andreas Färber
@ 2009-03-15 0:42 ` Paul Brook
2009-03-15 16:16 ` Stefan Weil
2009-03-16 10:22 ` Johannes Schindelin
1 sibling, 2 replies; 11+ messages in thread
From: Paul Brook @ 2009-03-15 0:42 UTC (permalink / raw)
To: qemu-devel; +Cc: Consul
> > But really funny think is the change that triggers the bug is precisely
> > this: -Monitor *cur_mon;
> > +Monitor *cur_mon = NULL;
> >
> > Obviously, kqemu is happier having garbage in the cur_mon than NULL
>
> I rather expect that to _hide_ the bug. The "garbage" might be a
> left-over from the heap.
This change does precisely nothing. In C all global and static variables are
implicitly zero initialized.
Paul
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-15 0:42 ` Paul Brook
@ 2009-03-15 16:16 ` Stefan Weil
2009-03-15 16:39 ` Avi Kivity
2009-03-16 10:22 ` Johannes Schindelin
1 sibling, 1 reply; 11+ messages in thread
From: Stefan Weil @ 2009-03-15 16:16 UTC (permalink / raw)
To: qemu-devel
Paul Brook schrieb:
>>> But really funny think is the change that triggers the bug is precisely
>>> this: -Monitor *cur_mon;
>>> +Monitor *cur_mon = NULL;
>>>
>>> Obviously, kqemu is happier having garbage in the cur_mon than NULL
>>>
>> I rather expect that to _hide_ the bug. The "garbage" might be a
>> left-over from the heap.
>>
>
> This change does precisely nothing. In C all global and static variables are
> implicitly zero initialized.
>
> Paul
>
>
>
This change changes the location of variable cur_mon from BSS to DATA
segment.
For buggy code, such changes surely can have an effect. Maybe some other
variable in data which is located before cur_mon destroys cur_mon.
Running in gdb with a hardware watchpoint on any change of cur_mon might
help
to see if cur_mon is overwritten.
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-15 16:16 ` Stefan Weil
@ 2009-03-15 16:39 ` Avi Kivity
0 siblings, 0 replies; 11+ messages in thread
From: Avi Kivity @ 2009-03-15 16:39 UTC (permalink / raw)
To: qemu-devel
Stefan Weil wrote:
> This change changes the location of variable cur_mon from BSS to DATA
> segment.
> For buggy code, such changes surely can have an effect. Maybe some other
> variable in data which is located before cur_mon destroys cur_mon.
>
> Running in gdb with a hardware watchpoint on any change of cur_mon might
> help
> to see if cur_mon is overwritten.
>
Another way to debug these issues is to look at the symbol map of a
known bad executable, and examine uses of variables immediately before
and after the corrupted variable. I've recently found a bug using this
method.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled
2009-03-15 0:42 ` Paul Brook
2009-03-15 16:16 ` Stefan Weil
@ 2009-03-16 10:22 ` Johannes Schindelin
1 sibling, 0 replies; 11+ messages in thread
From: Johannes Schindelin @ 2009-03-16 10:22 UTC (permalink / raw)
To: Paul Brook; +Cc: Consul, qemu-devel
Hi,
On Sun, 15 Mar 2009, Paul Brook wrote:
> > > But really funny think is the change that triggers the bug is precisely
> > > this: -Monitor *cur_mon;
> > > +Monitor *cur_mon = NULL;
> > >
> > > Obviously, kqemu is happier having garbage in the cur_mon than NULL
> >
> > I rather expect that to _hide_ the bug. The "garbage" might be a
> > left-over from the heap.
>
> This change does precisely nothing. In C all global and static variables
> are implicitly zero initialized.
True. I assumed that the lack of indentation was a mailer-induced
mistake, but looking at the source (which I did not have time to when
replying myself), you're correct, this initialization is in BSS, and
therefore implicitly NULL anyway.
So I agree that this change cannot be the regression (except if GCC4 has a
bug in BSS initialization, which I doubt rather strongly).
Ciao,
Dscho
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-03-16 10:20 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-07 0:39 [Qemu-devel] SIGSEGV on Windows with KQEMU enabled Consul
2009-03-07 2:51 ` Anthony Liguori
2009-03-13 1:28 ` [Qemu-devel] " Consul
2009-03-13 10:37 ` Johannes Schindelin
2009-03-13 17:33 ` Consul
2009-03-14 12:16 ` Johannes Schindelin
2009-03-14 12:36 ` Andreas Färber
2009-03-15 0:42 ` Paul Brook
2009-03-15 16:16 ` Stefan Weil
2009-03-15 16:39 ` Avi Kivity
2009-03-16 10:22 ` Johannes Schindelin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.