diff options
Diffstat (limited to 'results/scraper/launchpad/891002')
| -rw-r--r-- | results/scraper/launchpad/891002 | 44 |
1 files changed, 44 insertions, 0 deletions
diff --git a/results/scraper/launchpad/891002 b/results/scraper/launchpad/891002 new file mode 100644 index 00000000..f5df51b1 --- /dev/null +++ b/results/scraper/launchpad/891002 @@ -0,0 +1,44 @@ +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. + |
