win32: git rev 59f971d crashes when accessing disk (coroutine issue)

[Roy Tam]

Host: XP SP3 / Vista SP2

configure commandline: ./configure --target-list="i386-softmmu" --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable-linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags="-O0 -pipe"

gcc -v:
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32'
Thread model: win32
gcc version 4.3.3 (4.3.3-tdm-1 mingw32)

gdb output:
C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk
GNU gdb (GDB) 7.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
done.
(gdb) r
Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -hda xp.vmdk
[New Thread 2472.0x8e0]
[New Thread 2472.0xdc4]
[New Thread 2472.0x8f0]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2472.0x8f0]
0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll
(gdb) bt
#0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll
#1 0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8,
    action=COROUTINE_YIELD) at coroutine-win32.c:48
#2 0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8)
    at qemu-coroutine.c:31
#3 0x00411618 in bdrv_rw_co (bs=<optimized out>, sector_num=<optimized out>,
    buf=0x2140000 "@", nb_sectors=1, is_write=false) at block.c:1335
#4 0x00486e39 in ide_sector_read (s=0x1bbdaa0)
    at C:/msys/home/User/qemu/hw/ide/core.c:480
#5 0x0054e71f in memory_region_iorange_write (iorange=0x1bbcf60, offset=7,
    width=1, data=32) at C:/msys/home/User/qemu/memory.c:431
#6 0x005494e0 in ioport_writeb_thunk (opaque=0x1bbcf60, addr=7680, data=32)
    at C:/msys/home/User/qemu/ioport.c:211
#7 0x005496cf in ioport_write (data=<optimized out>,
    address=<optimized out>, index=<optimized out>)
    at C:/msys/home/User/qemu/ioport.c:82
#8 cpu_outb (addr=2147340288, val=0 '\000')
    at C:/msys/home/User/qemu/ioport.c:274
#9 0x022c0397 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

[Roy Tam (roytam)]

Same crash in wine:

user@gx110-lubuntu:~/qemu/i386-softmmu $ wine --version
wine-1.3.37
user@gx110-lubuntu:~/qemu/i386-softmmu $ winedbg qemu-system-i386.exe -L ..\\pc-bios -fda fda.img
WineDbg starting on pid 0024
0x7b85dedf: movl %edi,0x4(%esp)
Wine-dbg>cont
fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0080: stub!
fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0001: stub!
Unhandled exception: page fault on write access to 0x00000004 in 32-bit code (0x7b83ba1e).

Wine-dbg>bt all
(...)

Backtracing for thread 000d in process 0024 (Z:\home\user\qemu\i386-softmmu\qemu-system-i386.exe):
Backtrace:
=>0 0x7e06f832 GLIBC_2+0x832() in ld-linux.so.2 (0x0dd1e9b8)
  1 0x68621611 in winmm (+0x21610) (0x0dd1ea48)
  2 0x7bc70ed0 call_thread_func_wrapper+0xb() in ntdll (0x0dd1ea58)
  3 0x7bc7110d call_thread_func+0x7c() in ntdll (0x0dd1eb28)
  4 0x7bc70eae RtlRaiseException+0x21() in ntdll (0x0dd1eb48)
  5 0x7bc7acd5 in ntdll (+0x6acd4) (0x0dd1f398)
  6 0x6814696e start_thread+0xbd() in libpthread.so.0 (0x0dd1f498)

Backtracing for thread 0029 in process 0024 (Z:\home\user\qemu\i386-softmmu\qemu-system-i386.exe):
Backtrace:
=>0 0x7b83ba1e SwitchToFiber+0x1e() in kernel32 (0x04dde198)
  1 0x0044e368 qemu_coroutine_switch+0x37(from_=0x14730c, to_=0x16d430, action=COROUTINE_YIELD) [/home/user/qemu/coroutine-win32.c:48] in qemu-system-i386 (0x04dde1d8)
  2 0x004f4038 coroutine_swap+0x27(from=(nil), to=0x16d430) [/home/user/qemu/qemu-coroutine.c:31] in qemu-system-i386 (0x04dde208)
  3 0x00413c92 bdrv_rw_co+0x81(bs=<is not available>, sector_num=0x7ffd000000000000, buf="µ", nb_sectors=0x1, is_write=false) [/home/user/qemu/block.c:1335] in qemu-system-i386 (0x04dde268)
  4 0x004884e4 fdctrl_transfer_handler+0x1f3(opaque=0x1dd6d0, nchan=0x2, dma_pos=0, dma_len=0x200) [/home/user/qemu/hw/fdc.c:1162] in qemu-system-i386 (0x04dde4f8)
  5 0x0047f9e1 DMA_run+0xd0() [/home/user/qemu/hw/dma.c:348] in qemu-system-i386 (0x04dde548)
  6 0x00487286 fdctrl_start_transfer+0x2f5(fdctrl=0x1dd6d0, direction=0x1) [/home/user/qemu/hw/fdc.c:1093] in qemu-system-i386 (0x04dde5c8)
  7 0x0056b86d memory_region_iorange_write+0x9c(iorange=0x1df790, offset=0x4, width=0x1, data=0xff) [/home/user/qemu/memory.c:431] in qemu-system-i386 (0x04dde638)
  8 0x005666f7 ioport_writeb_thunk+0x46(opaque=0x1df790, addr=0x3f5, data=0xff) [/home/user/qemu/ioport.c:211] in qemu-system-i386 (0x04dde678)
  9 0x00566408 ioport_write+0x37(index=<is not available>, address=0x7ffd0000, data=0x4ddea70) [/home/user/qemu/ioport.c:82] in qemu-system-i386 (0x04dde6a8)
  10 0x01854496 (0x0015aab0)

Backtracing for thread 0025 in process 0024 (Z:\home\user\qemu\i386-softmmu\qemu-system-i386.exe):
Backtrace:
=>0 0x7e06f830 GLIBC_2+0x830() in ld-linux.so.2 (0x015bf368)
  1 0x7bc77563 in ntdll (+0x67562) (0x015bf598)
  2 0x7bc77835 NtWaitForMultipleObjects+0x54() in ntdll (0x015bf5c8)
  3 0x7b86f89f WaitForMultipleObjectsEx+0xee() in kernel32 (0x015bf718)
  4 0x7b86f91a WaitForMultipleObjects+0x39() in kernel32 (0x015bf748)
  5 0x004d4c6f main_loop_wait+0x5be(nonblocking=0) [/home/user/qemu/main-loop.c:387] in qemu-system-i386 (0x015bfac8)
  6 0x00...

[Stefan Hajnoczi (stefanha)]

On Wed, Feb 15, 2012 at 1:59 AM, Roy Tam <email address hidden> wrote:
> 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll
> (gdb) bt
> #0  0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll
> #1  0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8,
>    action=COROUTINE_YIELD) at coroutine-win32.c:48
> #2  0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8)
>    at qemu-coroutine.c:31
> #3  0x00411618 in bdrv_rw_co (bs=<optimized out>, sector_num=<optimized out>,
>    buf=0x2140000 "@", nb_sectors=1, is_write=false) at block.c:1335

This is interesting because the code is a straightforward usage of coroutines:

co = qemu_coroutine_create(bdrv_rw_co_entry);
qemu_coroutine_enter(co, &rwco); <--- boom

Please make test-coroutine and try ./test-coroutine. That performs
some sanity checks.

I haven't had time to look in depth yet but perhaps this worked in the
past and you could bisect it to find the commit that broke it?

Stefan

[Kevin Wolf (kwolf-redhat)]

Am 16.02.2012 10:34, schrieb Stefan Hajnoczi:
> This is interesting because the code is a straightforward usage of
> coroutines:
>
> co = qemu_coroutine_create(bdrv_rw_co_entry);
> qemu_coroutine_enter(co, &rwco); <--- boom
>
> Please make test-coroutine and try ./test-coroutine. That performs
> some sanity checks.
>
> I haven't had time to look in depth yet but perhaps this worked in the
> past and you could bisect it to find the commit that broke it?

Remember that I saw a similar crash a while ago? It was definitely a
NULL pointer access somewhere inside SwitchToFiber. I can't remember
exactly what came out of it, but I think you and Paolo couldn't
reproduce it and I ran out of time for debugging win32 stuff.

If I was to debug this, the first thing I would try is that I would dump
co->fiber (or actually I seem to remember it was some data structure
that is only pointed to by a field in co->fiber) immediately after the
coroutine is created (I think it was still okay then) and set a
watchpoint on it.

Kevin

[Roy Tam (roytam)]

2012/2/16 Kevin Wolf <email address hidden>:
> Am 16.02.2012 10:34, schrieb Stefan Hajnoczi:
>> This is interesting because the code is a straightforward usage of
>> coroutines:
>>
>> co = qemu_coroutine_create(bdrv_rw_co_entry);
>> qemu_coroutine_enter(co, &rwco);   <--- boom
>>
>> Please make test-coroutine and try ./test-coroutine.  That performs
>> some sanity checks.
>>
>> I haven't had time to look in depth yet but perhaps this worked in the
>> past and you could bisect it to find the commit that broke it?
>
> Remember that I saw a similar crash a while ago? It was definitely a
> NULL pointer access somewhere inside SwitchToFiber. I can't remember
> exactly what came out of it, but I think you and Paolo couldn't
> reproduce it and I ran out of time for debugging win32 stuff.
>
> If I was to debug this, the first thing I would try is that I would dump
> co->fiber (or actually I seem to remember it was some data structure
> that is only pointed to by a field in co->fiber) immediately after the
> coroutine is created (I think it was still okay then) and set a
> watchpoint on it.
>
> Kevin

A -O0 build traces: (I should put this in CFLAGS but not in --extra-cflags)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5688.0x17c0]
0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll
(gdb) bt
#0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll
#1 0x0045e98d in qemu_coroutine_switch (from_=0x18f93a4, to_=0x1b79648,
    action=COROUTINE_YIELD) at coroutine-win32.c:48
#2 0x004fea3f in coroutine_swap (from=0x18f93a4, to=0x1b79648)
    at qemu-coroutine.c:31
#3 0x004feb34 in qemu_coroutine_enter (co=0x1b79648, opaque=0x1fafa60)
    at qemu-coroutine.c:58
#4 0x00414e22 in bdrv_rw_co (bs=0x18f7fb0, sector_num=0, buf=0x20e0000 "@",
    nb_sectors=1, is_write=false) at block.c:1337
#5 0x00414e92 in bdrv_read (bs=0x18f7fb0, sector_num=0, buf=0x20e0000 "@",
    nb_sectors=1) at block.c:1349
#6 0x004a03d5 in ide_sector_read (s=0x1b5b9e0)
    at C:/msys/home/User/qemu/hw/ide/core.c:480
#7 0x0058872b in memory_region_iorange_write (iorange=0xdc32268, offset=7,
    width=1, data=32) at C:/msys/home/User/qemu/memory.c:431
#8 0x00583510 in ioport_writeb_thunk (opaque=0xdc32268, addr=7680, data=32)
    at C:/msys/home/User/qemu/ioport.c:211
#9 0x005836ff in ioport_write (data=<optimized out>,
    address=<optimized out>, index=<optimized out>)
    at C:/msys/home/User/qemu/ioport.c:82
#10 cpu_outb (addr=2147340288, val=0 '\000')
    at C:/msys/home/User/qemu/ioport.c:274
#11 0x02260397 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) frame 1
#1 0x0045e98d in qemu_coroutine_switch (from_=0x18f93a4, to_=0x1b79648,
    action=COROUTINE_YIELD) at coroutine-win32.c:48
48 SwitchToFiber(to->fiber);
(gdb) print to
$1 = (CoroutineWin32 *) 0x1b79648
(gdb) print *to
$2 = {base = {entry = 0x414cb0 <bdrv_rw_co_entry>, entry_arg = 0x1fafa60,
    caller = 0x18f93a4, pool_next = {le_next = 0x0, le_prev = 0x0},
    co_queue_next = {tqe_next = 0x0, tqe_prev = 0x0}}, fiber = 0x249e30,
  action = COROUTINE_YIELD}

[Roy Tam (roytam)]

2012/2/16 Kevin Wolf <email address hidden>:
> Am 16.02.2012 12:01, schrieb Paolo Bonzini:
>> On 02/16/2012 11:34 AM, Kevin Wolf wrote:
>>> Remember that I saw a similar crash a while ago? It was definitely a
>>> NULL pointer access somewhere inside SwitchToFiber. I can't remember
>>> exactly what came out of it, but I think you and Paolo couldn't
>>> reproduce it and I ran out of time for debugging win32 stuff.
>>>
>>> If I was to debug this, the first thing I would try is that I would dump
>>> co->fiber (or actually I seem to remember it was some data structure
>>> that is only pointed to by a field in co->fiber) immediately after the
>>> coroutine is created (I think it was still okay then) and set a
>>> watchpoint on it.
>>
>> IIRC the problem was that thread-local storage was not thread-local at all.
>
> Ah, right. And we didn't introduce a workaround, so I guess this is the
> same thing.
>
> Do newer mingw versions get this right or were you just lucky and we
> should look for some kind of workaround?
>

Does QEMU calls ConvertThreadToFiber() in I/O Thread?
From thread notes located in
http://www.lisphacker.com/temp/threading-notes.txt :

  * Before a Thread can call SwitchToFiber() it must call
    ConvertThreadToFiber(), but there is no way prior to Vista
    to know if a Thread created by alien code is already a
    Fiber, and the documentation is spectacularly unclear on the
    consequences of using the Fiber functions improperly (such
    as calling SwitchToFiber() without calling
    ConvertThreadToFiber() or calling ConvertThreadToFiber()
    when the Thread has already been converted).

If so, we may hitting this issue.

> Kevin
>

Roy

[Stefan Weil (ubuntu-weilnetz)]

The crash is caused by non-working thread local storage (TLS) in coroutine-win32.c.

It took me some time to analyze this bug because I don't get it in my native w32 environment with gcc-4.6.2,
but I could reproduce it with cross compiled w32 code. SwitchToFiber crashed because it was called with a
TIB (http://en.wikipedia.org/wiki/Win32_Thread_Information_Block) which belonged to a thread which was
not converted to a fiber. ConvertThreadToFiber was not called for this thread because TLS "current" was
not thread local.

Please try these modified configure option which adds the compiler flag needed for multithreading:
--extra-cflags="-O0 -pipe -mthreads". For me, -mthreads solved the problem.

Regards,
Stefan Weil

[Roy Tam (roytam)]

2012/2/17 Stefan Weil <email address hidden>:
> The crash is caused by non-working thread local storage (TLS) in
> coroutine-win32.c.
>
> It took me some time to analyze this bug because I don't get it in my native w32 environment with gcc-4.6.2,
> but I could reproduce it with cross compiled w32 code.  SwitchToFiber crashed because it was called with a
> TIB (http://en.wikipedia.org/wiki/Win32_Thread_Information_Block) which belonged to a thread which was
> not converted to a fiber. ConvertThreadToFiber was not called for this thread because TLS "current" was
> not thread local.
>
> Please try these modified configure option which adds the compiler flag needed for multithreading:
> --extra-cflags="-O0 -pipe -mthreads". For me, -mthreads solved the problem.
>

Yes "-mthreads" switch does workaround the issue.
But using "-mthreads" making resulting binaries depend on
mingwm10.dll, which is not good.

> Regards,
> Stefan Weil

[Roy Tam (roytam)]

2012/2/17 Roy Tam <email address hidden>:
> 2012/2/17 Stefan Weil <email address hidden>:
>> The crash is caused by non-working thread local storage (TLS) in
>> coroutine-win32.c.
>>
>> It took me some time to analyze this bug because I don't get it in my native w32 environment with gcc-4.6.2,
>> but I could reproduce it with cross compiled w32 code.  SwitchToFiber crashed because it was called with a
>> TIB (http://en.wikipedia.org/wiki/Win32_Thread_Information_Block) which belonged to a thread which was
>> not converted to a fiber. ConvertThreadToFiber was not called for this thread because TLS "current" was
>> not thread local.
>>
>> Please try these modified configure option which adds the compiler flag needed for multithreading:
>> --extra-cflags="-O0 -pipe -mthreads". For me, -mthreads solved the problem.
>>
>
> Yes "-mthreads" switch does workaround the issue.
> But using "-mthreads" making resulting binaries depend on
> mingwm10.dll, which is not good.
>

And also it still crash when quitting:
Program received signal SIGSEGV, Segmentation fault.
0x00609bfb in emutls_destroy (ptr=0x1959418)
    at ../../../gcc-4.3.3/libgcc/../gcc/emutls.c:76
76 ../../../gcc-4.3.3/libgcc/../gcc/emutls.c: No such file or directory.
        in ../../../gcc-4.3.3/libgcc/../gcc/emutls.c
(gdb) bt
#0 0x00609bfb in emutls_destroy (ptr=0x1959418)
    at ../../../gcc-4.3.3/libgcc/../gcc/emutls.c:76
#1 0x6fbc1263 in __mingwthr_run_key_dtors ()
   from C:\msys\home\User\qemu\i386-softmmu\mingwm10.dll
#2 0x6fbc1408 in __dyn_tls_dtor@12 ()
   from C:\msys\home\User\qemu\i386-softmmu\mingwm10.dll
#3 0x6fbc0000 in ?? ()
#4 0x7c9424ca in ntdll!RtlDestroyQueryDebugBuffer ()
   from C:\WINDOWS\system32\ntdll.dll
#5 0x7c81caae in KERNEL32!IsValidLocale ()
   from C:\WINDOWS\system32\kernel32.dll
#6 0x7c81cb26 in KERNEL32!ExitProcess ()
   from C:\WINDOWS\system32\kernel32.dll
#7 0x77c09d45 in strerror () from C:\WINDOWS\system32\msvcrt.dll
#8 0x77c09e78 in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll
#9 0x77c09e90 in msvcrt!exit () from C:\WINDOWS\system32\msvcrt.dll
#10 0x006024dc in console_main ()
#11 0x00602594 in WinMain@16 ()
#12 0x00601db8 in main ()

>> Regards,
>> Stefan Weil

[Eric Lassauge (gozer)]

More or less same crash for me:
Using built-in specs.
COLLECT_GCC=d:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)

Host WinXP SP3 - Qemu-1.0.1

Maybe it can help:

Some stack frame (breakpoint set with command "where; continue" on function qemu_coroutine_switch():

Breakpoint 1, qemu_coroutine_switch (from_=0x1989f34, to_=0x209df00, action=COROUTINE_YIELD) at coroutine-win32.c:41
41 {
#0 qemu_coroutine_switch (from_=0x1989f34, to_=0x209df00, action=COROUTINE_YIELD) at coroutine-win32.c:41
#1 0x004c3fe6 in _fu6882____stack_chk_guard () at qemu-coroutine.c:31
#2 0x00410e1e in _fu528____stack_chk_guard () at block.c:2518
#3 0x00403152 in _fu35____stack_chk_guard () at async.c:71
#4 0x004a7a8e in _fu5545____stack_chk_guard () at main-loop.c:472
#5 0x004a27db in main_loop () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\vl.c:1481
#6 _fu5383____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\vl.c:3485
#7 0x004a3b2a in _fu5385____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\vl.c:102
#8 0x005ddcf9 in console_main (argc=20, argv=0x1985d00) at ./src/main/win32/SDL_win32_main.c:315
#9 0x005dddbb in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x241f18 "-L Bios -k fr -vga std -soundhw es1370 -boot menu=on,splash=bootsplash.bmp,splash-time=5000 -rtc base=localtime,clock=host -name linux-0.2 -drive file=linux-0.2.img,media=disk,cache=writeback -no-acpi"..., sw=10) at ./src/main/win32/SDL_win32_main.c:398
#10 0x005dd45a in main (argc=) at ../mingw/main.c:73
[Switching to Thread 5316.0xda0]

Breakpoint 1, qemu_coroutine_switch (from_=0x1989f34, to_=0x1bcf900, action=COROUTINE_YIELD) at coroutine-win32.c:41
41 {
#0 qemu_coroutine_switch (from_=0x1989f34, to_=0x1bcf900, action=COROUTINE_YIELD) at coroutine-win32.c:41
#1 0x004c3fe6 in _fu6882____stack_chk_guard () at qemu-coroutine.c:31
#2 0x0041543d in _fu757____stack_chk_guard () at block.c:2657
#3 0x00472b95 in _fu3751____stack_chk_guard ()
#4 0x00554e1b in _fu11201____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\memory.c:446
#5 0x0054e5a8 in _fu10980____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\ioport.c:211
#6 0x0054eb9d in ioport_write (data=<optimized out>, address=503, index=0) at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\ioport.c:82
#7 _fu10998____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\ioport.c:274
#8 0x026680cf in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Program received signal SIGILL, Illegal instruction.
0x68ac12ca in ?? () from d:\documents\lassauge\qemu-windows\libssp-0.dll
(gdb) at address 0xbaadf011
Cannot access memory at address 0xbaadf011
Cannot access memory at address 0xbaad...

[Roy Tam (roytam)]

coroutine issue again, when booting tinycore_3.3.iso:

C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios -cdrom tinycore_3.3.iso
GNU gdb (GDB) 7.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
done.
(gdb) r
Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..
\\pc-bios -cdrom tinycore_3.3.iso
[New Thread 10072.0x2318]
[New Thread 10072.0x2050]
[New Thread 10072.0x29fc]
*** stack smashing detected ***: terminated

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 10072.0x29fc]
0x00634a4a in fail.isra.0 ()
(gdb) bt
#0 0x00634a4a in fail.isra.0 ()
#1 0x00634ab2 in __stack_chk_fail ()
#2 0xa6782315 in ?? ()
#3 0x00000bda in ?? ()
#4 0x00000001 in ?? ()
#5 0x0044b9b9 in qemu_coroutine_switch (from_=0x22f848, to_=0x7c92e920,
    action=0) at coroutine-win32.c:50
#6 0x000cef9f in ?? ()
#7 0x0022f848 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

http://<email address hidden>/msg103426.html may refer to this too.

[Stefan Weil (ubuntu-weilnetz)]

Please try a newer compiler. gcc-4.6.2 compiles thread local storage correctly, gcc-4.3.3 obviously doesn't.
If you can confirm that newer compilers fix this bug, I'd like to close this ticket.

[Roy Tam (roytam)]

2012/3/20 Stefan Weil <email address hidden>:
> Please try a newer compiler. gcc-4.6.2 compiles thread local storage correctly, gcc-4.3.3 obviously doesn't.
> If you can confirm that newer compilers fix this bug, I'd like to close this ticket.
>

I'm using gcc-4.6.2 now.

> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/932487
>
> Title:
>  win32: git rev 59f971d crashes when accessing disk (coroutine issue)
>
> Status in QEMU:
>  Confirmed
>
> Bug description:
>  Host: XP SP3 / Vista SP2
>
>  configure commandline: ./configure --target-list="i386-softmmu"
>  --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable-
>  linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags="-O0
>  -pipe"
>
>  gcc -v:
>  Using built-in specs.
>  Target: mingw32
>  Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32'
>  Thread model: win32
>  gcc version 4.3.3 (4.3.3-tdm-1 mingw32)
>
>  gdb output:
>  C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk
>  GNU gdb (GDB) 7.3
>  Copyright (C) 2011 Free Software Foundation, Inc.
>  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>  This is free software: you are free to change and redistribute it.
>  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>  and "show warranty" for details.
>  This GDB was configured as "mingw32".
>  For bug reporting instructions, please see:
>  <http://www.gnu.org/software/gdb/bugs/>...
>  Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
>  done.
>  (gdb) r
>  Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -hda xp.vmdk
>  [New Thread 2472.0x8e0]
>  [New Thread 2472.0xdc4]
>  [New Thread 2472.0x8f0]
>
>  Program received signal SIGSEGV, Segmentation fault.
>  [Switching to Thread 2472.0x8f0]
>  0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll
>  (gdb) bt
>  #0  0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll
>  #1  0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8,
>      action=COROUTINE_YIELD) at coroutine-win32.c:48
>  #2  0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8)
>      at qemu-coroutine.c:31
>  #3  0x00411618 in bdrv_rw_co (bs=<optimized out>, sector_num=<optimized out>,
>      buf=0x2140000 "@", nb_sectors=1, is_write=false) at block.c:1335
>  #4  0x00486e39 in ide_sector_read (s=0x1bbdaa0)
>      at C:/msys/home/User/qemu/hw/ide/core.c:480
>  #5  0x0054e71f in memory_region_iorange_write (iorange=0x1bbcf60, offset=7,
>      width=1, data=32) at C:/msys/home/User/qemu/memory.c:431
>  #6  0x005494e0 in ioport_writeb_thunk...

[Stefan Weil (ubuntu-weilnetz)]

Fixed in newer versions which no longer have problems with thread local storage on Windows.