http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #12 from Jeremy White jwhite@codeweavers.com 2009-06-07 20:01:44 --- Took another stab at this and spent a day or two on it. I tried to back track, and tested using only the hack to prevent the divide by zero exception.
There seems to be one fundamental issue - the Lotro exception handler seems to spin out of control, and dies of a stack over run. However, there seem to be two different, fairly reproducible, cases of failure.
The first one happens immediately after startup. You get: setup_exception_record nested exception on signal stack in thread 001d... and you're dead. You can connect with a debugger and hunt around, but nothing obvious jumps out.
The second one is the one that happens caused by the the RSS feed reading thread. This one is a c0000005 exception that goes into an infinite spin loop and eventually blows the stack. It happens after things begin to cook and we've started to put up the form.
There doesn't seem to be any certainty as to which of these two failures I'll get when I launch TurbineInvoker, but I always get one of them (more often the second than the first).
I spent a lot of time looking over the use of Overlapped io with winsock, along with IO Completion Ports, in the hope that something in the way the RSS feed was received was wrong. There is odd behavior, but it all seems intentional (and bug free :-/). That is, you'll have one thread do a WSARecv which sets up overlapped io. Another thread will do a GetQueuedCompletionStatus to pull the data, and then the first thread will repeat the WSARecv. Another thread might pull the next completion status, and so on, until you get to near the end of the RSS feed. Then we pull the last 6 bytes (a \r\n, 0^\r\n, and a ^\r\n) off with straight up recv()s of 2, 1, 2, and 2. Odd, but apparently intentional.
It certainly wouldn't hurt to write some good tests for this; there may be some gotchas hiding in there, particularly mixing overlapped w/io completion routines and 'normal' recv()s, but I couldn't find any.
Someone smarter than I am may also be more able to extract better information from winedbg as to what's causing the c0000005 exception.