[Qemu-devel] SIGSEGV on Windows with KQEMU enabled

[Qemu-devel] SIGSEGV on Windows with KQEMU enabled

[Consul]

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)

Re: [Qemu-devel] SIGSEGV on Windows with KQEMU enabled

[Anthony Liguori]

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)
>
>
>
>

[Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Consul]

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).

Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Johannes Schindelin]

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

[Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Consul]

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
> 
> 
> 
> 

Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Johannes Schindelin]

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

Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Andreas Färber]

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

Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Paul Brook]

> > 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

Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Stefan Weil]

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

Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Avi Kivity]

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

Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled

[Johannes Schindelin]

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