http://bugs.winehq.org/show_bug.cgi?id=10467 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #9240 is|0 |1 obsolete| | --- Comment #60 from Anastasius Focht <focht(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.