http://bugs.winehq.org/show_bug.cgi?id=10503
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #8 from Anastasius Focht focht@gmx.net 2007-11-19 14:24:41 --- Hello,
--- snip --- This sounds like something that could generate a segmentation fault? --- snip ---
sure. That initial posting in the link you provided pretty summed it up.
That game code is "abusing" ESP while writing to DIB region, resulting in access violation exception. Wine detects the stack pointer being outside of thread stack range and hence the warning. Actually wine kills itself (double fault) when building the stack frame for the raise function by relying on that invalid ESP from signal context (despite the warning).
--- quote --- So, what I'm wondering is if anyone who has experiance with the exception handling code has any thoughts on how this problem can be fixed. --- quote ---
Well, general rule: do not rely on faulting context ESP while setting up exception handling stuff Wine has no knowledge at this point that the faulting thread is actually abusing ESP. There might be cases where the abused "counter" ESP has coincidentally a "good" value (within thread stack limits) but wine cannot make safe assumptions at this point (only print diagnostics).
A solution would be to generally use an alternate stack to build the raise frame. Maybe a specially reserved area, a stack page between TEB stack guard and NtCurrentTeb()->Tib.StackLimit to safely build the frame. This would prevent wine from accidentally damaging/overwriting parts of the faulting thread stack with the raise frame, causing double faults.
Regards