Sebastian Lackner sebastian@fds-team.de writes:
On 18.04.2016 12:27, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
Signed-off-by: Sebastian Lackner sebastian@fds-team.de
When applications switch to a custom stack, exit_frame is not necessarily valid anymore.
How does it become invalid? Does the app unmap the previous stack?
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?