windows mingw compiled qemu-system-x86_64 crash on startup

qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env
$3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0}

it's compiled on windows 2003 and using mingw gcc version 4.6.1


On Wed, Nov 16, 2011 at 7:01 AM, humeafo <email address hidden> wrote:
> Public bug reported:
>
> qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env
> $3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0}

Kevin: Is this similar to the issue you found with your mingw cross-compiler?

Stefan


Am 16.11.2011 11:35, schrieb Stefan Hajnoczi:
> On Wed, Nov 16, 2011 at 7:01 AM, humeafo <email address hidden> wrote:
>> Public bug reported:
>>
>> qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env
>> $3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0}
> 
> Kevin: Is this similar to the issue you found with your mingw cross-compiler?

The symptoms were different. I didn't get a broken TCG state but some
internals of the Fiber used for coroutines must have been corrupted
(SwitchFiber() crashed when dereferencing a null pointer, but the
externally visible pointer that qemu passed to it was still ok).

Maybe both could be symptoms of the same kind of memory corruption.

Kevin


maybe it's caused by mingw/gcc? the same binary runs well on win7-x64, but not on win2003-32 bit I'll do more test, if I've time, i'd debug it and try to find the reason

after some debugging I confirmed that this is caused by a mingw gcc 4.6.1-2 optiomization bug, gcc generated optimized code that used ebp to store some results , while later ebp is used  in setjmp and longjmp, so a beiju occurred. mingw gcc 4.5.2works well.  the bug should be closed.

Closing according to comment #5.