x86: 0.878
TCG: 0.781
architecture: 0.724
peripherals: 0.692
performance: 0.601
debug: 0.590
user-level: 0.587
semantic: 0.523
files: 0.497
device: 0.455
hypervisor: 0.397
graphic: 0.374
PID: 0.351
permissions: 0.324
boot: 0.318
network: 0.316
register: 0.314
ppc: 0.261
risc-v: 0.251
kernel: 0.248
vnc: 0.246
VMM: 0.240
socket: 0.239
mistranslation: 0.234
virtual: 0.210
KVM: 0.202
arm: 0.183
assembly: 0.096
i386: 0.092

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.