http://bugs.winehq.org/show_bug.cgi?id=10467
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9238 is|0 |1 obsolete| |
--- Comment #8 from Anastasius Focht focht@gmx.net 2007-11-18 13:48:45 --- Created an attachment (id=9240) --> (http://bugs.winehq.org/attachment.cgi?id=9240) patch to fix bottom stack guard page to allow CLR exceptions from .NET runtime to succeed
Hello
--- quote --- That won't work. Wine does not grow stack. And does not use guard page. --- quote ---
--- quote --- When I did some testing on winnt+ the guard page was used only to grow stack. When the maximal stack size was reached (when it could not be grown anymore because of reserved space in the lover address space) windows allocated page with PAGE_NOACCESS. Exactly what Wine does now. Just allocating the maximum stack size instead. --- quote ---
Did you actually bother to read? I *never* intended to implement/mimick any dynamic stack growth using PAGE_GUARD like NT does. I just marked a single guard page location at bottom of stack and adjusted flags accordingly. O-N-E single stack guard page at thread stack B-O-T-T-O-M. If there is a guard page violation due to stack overflow then the usual overflow handling has to be extended to handle this case (just like wine currently does when PAGE_NOACCESS guard is encountered). There is no growth further. The app would be killed anyway.
--- quote --- So if what you saying is true the bug is in .net not Wine. However it would be nice for Wine to support growing stack. --- quote ---
This is the way windows NT based operating systems work. The Microsoft .NET runtime was never intended to run on other operating systems (except of shared source rotor, which differs in aspects). Why should the MS .NET runtime developers actually care that wine doesn't support this stuff?
--- quote --- What you did won't work for some programs that clear _whole stack space_ on exit. On windows they trigger stack growth. On Wine they just crash. --- quote ---
And? Whats the problem? In the rare cases such brain damaged programs won't work anymore just add internal last chance PAGE_GUARD violation handler, which clears the guard page flag and resume malware cleanup process. Done.
Anyway attached is version which takes user threads into account. This lets multithreaded .NET apps succeed too, which throw CLR exceptions from other than main thread.
Regards