http://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9240 is|0 |1 obsolete| |
--- Comment #60 from Anastasius Focht focht@gmx.net 2008-04-02 15:48:43 --- (From update of attachment 9240) Hello,
--- quote --- I looked into this, actually it doesn't start looking from StackLimit but from the base of the stack, so it should work fine to add a guard page below StackLimit the way it is on Windows. --- quote ---
Search start is stack allocation base + page_size (VirtualQuery) which was coincidentally StackLimit in the wine thread stack implementation before the fix.
By moving StackLimit to not include the newly added guard page (base + 2*page_size) your implementation preserves NT compatibility and looks obviously more correct ;-)
Besides the required page guard at stack base + page_size, .NET uncovered another page guard problem here.
I think wine should still be able to handle cases where apps try to setup page guard in current thread stack frame (using address of local variable) - at least preventing the segfault triggered by glibc mprotect code.
For this problem do you want a bug report? Though that's low priority then.
---
When the case mapping table "l_intl.nls" is autogenerated (see comment #27) this bug will be finished.
Install issues like NTFS junctions (XP config) are covered by other bug reports.
Regards