[jira] Closed: (HARMONY-5819) [drlvm][signals] Not enough stack for SO processing in pure native threads

["Mark Hindess (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Hindess closed HARMONY-5819.
---------------------------------


This seems to be resolved completely.

> [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
>         Attachments: H-5819.patch, H-5819.patch, H-5819.patch
>
>
> 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.