2012/2/16 Kevin Wolf <kw...@redhat.com>: > 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
