http://bugs.winehq.org/show_bug.cgi?id=60281 --- Comment #3 from Victor <victormorel.pro@gmail.com> --- Following up on the register state above, with what we think the possible fix directions are — and a question for whoever knows this code. What we think happens --------------------- An exception is taken while the thread is somewhere around the stack switch in syscall_32to64. At that moment the host stack is still parked in R14 and RSP holds the guest stack. call_seh_handlers on the 64-bit side then unwinds from that context, and is_valid_frame measures the resulting establisher frame against NtCurrentTeb()->Tib.StackLimit/StackBase, which are the host bounds. The frame cannot pass, the exception is not dispatched, and the process dies on what is usually a longjmp. Directions we can see --------------------- 1. Give the thunk real unwind information, so the unwinder stops at it. If RtlVirtualUnwind treated syscall_32to64 as a boundary rather than walking through it into the guest stack, the validity check would never be reached with a guest frame. This looks like the cleanest of the three, and it is in the same spirit as the existing special-casing of BTCpuSimulate for relay. 2. Repair the context before dispatching. Recognise a RIP inside the thunk's range and reconstruct the intended state — put RSP and R14 back the way they belong — before letting dispatch proceed. More surgical, but it needs the thunk's boundaries to be known to the exception path, and it has to distinguish "before the swap" from "after". 3. Select the guest stack bounds when the exception came from 32-bit mode. We would argue against this one. It would silence the message, but the unwinder would then continue on a state we already know to be wrong, trading a loud failure for a quiet one. There is also the headroom question from comment 1, which we think is a second, partly independent facet: even with the bounds sorted out, an exception taken when the stack is nearly full still has to be recoverable. Our ulimit workaround only buys room, it does not address that. What we can offer ----------------- We have not built Wine yet — the report above comes from reading the source alongside our traces. We are willing to build an instrumented tree and collect whatever is useful: RSP, R14, R13, RIP around the xchgq, how often an exception actually lands inside that window, and whether the swap is genuinely mid-flight or already corrupt on entry. We also have a measurement protocol that survives the noise: this failure rate is dispersed enough that a single series proves nothing — our unmodified configuration ranged from 3 to 12 attempts per three launches — so we alternate conditions and use ten launches or more per arm. We can run that against a patched build. The question, then: is direction 1 the one worth trying, or is there a reason the thunk deliberately has no unwind information that we are not seeing? We would rather ask than send a patch that misses the point. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.