ntdll: Ignore invalid exit_frame when exiting thread.
sebastian at fds-team.de
Mon Apr 18 10:38:56 CDT 2016
On 18.04.2016 12:53, Alexandre Julliard wrote:
>> Yes, MSYS2/Cygwin will switch to its own stack and deallocate the old one.
>> This patch alone is not sufficient because there are still a couple of other
>> references to the old stack (like the debug_info struct in start_thread).
>> If preferred, this issue can also be solved differently by calculting exit_frame
>> dynamically based on StackBase (after a couple of other bugs are fixed).
>> Disadvantage is that if applications mess around with StackBase, I'm not sure if
>> we should trust that the new stack is set up properly.
> The reason for exit_frame is to prevent pthread_exit from trying to
> unwind the stack. I'm wondering how that will work if it was
> deallocated. Did you look into this? Does pthread detect that we are on
> a different stack? And doesn't pthread also put its own structures on
> the stack?
Some versions of pthread indeed put internal structures at the top of the stack.
To solve that, the current Staging patchset allocates threads with a dummy pthread,
and then switches to the real stack, see:
Unless there is something weird going on, thanks to the CFI annotations in
wine_switch_to_stack() pthread should be able to unwind the stack correctly despite
the stack switch inbetween. At least I have not found any problems so far ;)
You are right that ignoring exit_frame might (under specific circumstances)
run language handlers, but I'm not yet aware of a better way to deal with this.
The only alternative would be to calculate it based on StackBase, but its also
far from perfect.
More information about the wine-devel