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