Re: [Qemu-devel] qemu-system-sparc io-thread segfault on win32

[Bob Breuer]

Mark Cave-Ayland wrote:
> On 17/10/11 05:39, Bob Breuer wrote:
> 
>> I'm getting a segfault from qemu-system-sparc with the io thread enabled
>> on win32.  This is with the latest mingw (gcc 4.6.1).  mipsel also
>> fails, but i386 is ok.  I haven't checked any of the other system
>> targets, but they might also show this problem.
>>
>> git bisect points to commit cea5f9a cpu-exec.c: avoid AREG0 use, but
>> that would seem to only expose the bug instead of creating it.  In
>> cpu_exec(), assigning any valid pointer to ebp before setjmp will get it
>> working again.  It looks like a bogus value in ebp at the time of setjmp
>> will cause longjmp to abort on win32.
>>
>> Here's some output from gdb for the crash:
>>    Starting program:
>> d:\qemu\build-mingw\sparc-softmmu\qemu-system-sparc.exe
>>    -m 64 -L ./qemu-git/pc-bios
>>    [New Thread 2128.0x664]
>>    [New Thread 2128.0x5d4]
>>    [New Thread 2128.0x6dc]
>>    [Switching to Thread 2128.0x6dc]
>>
>>    Breakpoint 1, 0x00514a30 in _setjmp ()
>>    (gdb) info registers
>>    eax            0x1989b7c        26778492
>>    ecx            0x1982008        26746888
>>    edx            0x0      0
>>    ebx            0x1982008        26746888
>>    esp            0x378fe00        0x378fe00
>>    ebp            0xfffffffe       0xfffffffe
>>    esi            0x0      0
>>    edi            0x1982008        26746888
>>    eip            0x514a30 0x514a30<_setjmp>
>>    eflags         0x202    [ IF ]
>>    cs             0x1b     27
>>    ss             0x23     35
>>    ds             0x23     35
>>    es             0x23     35
>>    fs             0x38     56
>>    gs             0x0      0
>>    (gdb) c
>>    Continuing.
>>
>>    Program received signal SIGSEGV, Segmentation fault.
>>    0x7800bd65 in abnormal_termination () from
>> C:\WINNT\system32\msvcrt.dll
>>    (gdb) bt
>>    #0  0x7800bd65 in abnormal_termination () from
>> C:\WINNT\system32\msvcrt.dll
>>    #1  0x0378ffa4 in ?? ()
>>    Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>
>> Bob
> 
> Hi Bob,
> 
> I wonder if you're being caught out by some of the missing
> free()/g_free() substitutions? (patches for some of which have been
> posted to the list over the last few days). I'm fairly sure from
> previous experience that Windows has a limitation in that the DLL that
> claimed the memory must be the one to free it, otherwise you get some
> strange internal exceptions.
> 

I don't think this is a free/g_free issue.  If I use the following
patch, then I at least get the openbios messages:

diff --git a/cpu-exec.c b/cpu-exec.c
index a9fa608..dfbd6ea 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState
 /* main execution loop */

 volatile sig_atomic_t exit_request;
+register void *ebp asm("ebp");

 int cpu_exec(CPUState *env)
 {
@@ -233,6 +234,8 @@ int cpu_exec(CPUState *env)

     /* prepare setjmp context for exception handling */
     for(;;) {
+        int dummy = 0;
+        ebp = &dummy;
         if (setjmp(env->jmp_env) == 0) {
             /* if an exception is pending, we execute it here */
             if (env->exception_index >= 0) {


Google finds a mention of longjmp failing with -fomit-frame-pointer:
http://lua-users.org/lists/lua-l/2005-02/msg00158.html

Looks like gcc 4.6 turns on -fomit-frame-pointer by default.

Bob