You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Ilya Berezhniuk (JIRA)" <ji...@apache.org> on 2008/05/12 01:57:55 UTC
[jira] Created: (HARMONY-5819) [drlvm][signals] Not enough stack
for SO processing in pure native threads
[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.
[jira] Updated: (HARMONY-5819) [drlvm][signals] Not enough stack
for SO processing in pure native threads
Posted by "Ilya Berezhniuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ilya Berezhniuk updated HARMONY-5819:
-------------------------------------
Patch Info: [Patch Available]
> [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
>
>
> 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.
[jira] Updated: (HARMONY-5819) [drlvm][signals] Not enough stack
for SO processing in pure native threads
Posted by "Ilya Berezhniuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ilya Berezhniuk updated HARMONY-5819:
-------------------------------------
Attachment: H-5819.patch
The updated patch to compile after r659108.
> [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.
[jira] Closed: (HARMONY-5819) [drlvm][signals] Not enough stack for
SO processing in pure native threads
Posted by "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.
[jira] Resolved: (HARMONY-5819) [drlvm][signals] Not enough stack
for SO processing in pure native threads
Posted by "Ilya Berezhniuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ilya Berezhniuk resolved HARMONY-5819.
--------------------------------------
Resolution: Fixed
Applied at r663534.
> [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.
[jira] Updated: (HARMONY-5819) [drlvm][signals] Not enough stack
for SO processing in pure native threads
Posted by "Ilya Berezhniuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ilya Berezhniuk updated HARMONY-5819:
-------------------------------------
Attachment: H-5819.patch
Attaching the patch which implements function calls on alternative stack for Windows.
The patch fixes the problem for both 32-bit and 64-bit Windows.
> [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
>
>
> 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.
[jira] Updated: (HARMONY-5819) [drlvm][signals] Not enough stack
for SO processing in pure native threads
Posted by "Ilya Berezhniuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ilya Berezhniuk updated HARMONY-5819:
-------------------------------------
Attachment: H-5819.patch
Preliminary patch - please do not commit.
> [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
>
>
> 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.