harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-5819) [drlvm][signals] Not enough stack for SO processing in pure native threads
Date Sun, 11 May 2008 23:57:55 GMT
[drlvm][signals] Not enough stack for SO processing in pure native threads
--------------------------------------------------------------------------

                 Key: HARMONY-5819
                 URL: https://issues.apache.org/jira/browse/HARMONY-5819
             Project: Harmony
          Issue Type: Bug
          Components: DRLVM
         Environment: Windows
            Reporter: Ilya Berezhniuk
            Priority: Minor


When stack overflow occurs in pure native thread (i.e. not created not through Portlib or
HyThread), thread stack layout is like Windows created.

There are 3 pages from stack end: 1 guard page (when SO occured), then 1 normal page with
read/write access, and 1 not committed page. So total stack amount for SO processing is 8Kb.

When printing crash dump, SymInitialize() function is called to initialize DBGHelp library.
This call consumes >8Kb, so VM runs out of accessible stack memory and crashes with ACCESS_VIOLATION.

I tried to commit last uncommitted page to increase remaining stack on 4Kb. This solves the
problem on Windows/x86 - the patch is in attachment.
But this does not help on Windows/x86_64 - SymInitialize() call takes > 12Kb so one additional
page is still not enough.

I think the first patch should not be attached - it's workaround only.
I'm now working on complete solution - I try to call crash processing on specially allocated
alternative stack.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message