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] Updated: (HARMONY-5617) [drlvm] On Linux crash handler may crash itself when handling SOE condition
Date Sun, 23 Mar 2008 09:21:24 GMT

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

Ilya Berezhniuk updated HARMONY-5617:
-------------------------------------

    Attachment: H-5617-workaround.patch

I suggest the following patch as a workaround for the problem.
With this patch Port SIGSEGV handler restores access to 1 (or 2) pages in the stack where
signal has occured, to let VM signal handlers process it.
The patch also corrects a bit incorrect change from HARMONY-5624 (SO can occur in native code,
so corresponding checking should be divided on 2 stages).

The patch is a workaround only. It works fine, but it makes undesired dependency between Port
and VM core, and breaks crash processing for SIGSEGV signal.
I think the issue should be left open, until proper solution is implemented.

Actually Port should provide guard page setting/clearing by itself, and also detect when SIGSEGV
is actually a stack overflow.
Unfortunately, this will require moving another part of OS-dependent threading functions from
the VM HyThread module to the Port, and also moving fast TLS access to the Port.
It's good from design and modularity POV, but it can affect performance and needs accurate
changes and testing.
So I suggest committing this workaround and leaving the issue open for further work.

> [drlvm] On Linux crash handler may crash itself when handling SOE condition
> ---------------------------------------------------------------------------
>
>                 Key: HARMONY-5617
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5617
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>    Affects Versions: 5.0M6
>         Environment: Linux x86 and x86_64
>            Reporter: Gregory Shimansky
>            Priority: Minor
>         Attachments: H-5617-workaround.patch
>
>
> When crash handler receives a SIGSEGV signal that is caused by a stack overflow, it tries
to transfer control out of signal handler (just like it does for other kind of signals). But
the problem is that it tries to write memory pointed to by SP register (ESP or RSP) of the
original crash context. When crash happened because of stack overflow, writing to that memory
may not be possible since it is protected by a guard page. In this case crash handler crashes
itself:
> Program terminated with signal 11, Segmentation fault.
> #0  0x00002aaaaac27bbf in port_set_longjump_regs (fn=0x2aaaaac2658e, regs=0x7fffbd422b90,
num=3)
>     at /home/gregory/work/64/trunk/working_vm/vm/port/src/thread/linux/thread_em64t.c:86
> 86          *sp = (void*)regs->rip;
> (gdb) bt
> #0  0x00002aaaaac27bbf in port_set_longjump_regs (fn=0x2aaaaac2658e, regs=0x7fffbd422b90,
num=3)
>     at /home/gregory/work/64/trunk/working_vm/vm/port/src/thread/linux/thread_em64t.c:86
> #1  0x00002aaaaac26579 in general_signal_handler (signum=11, info=0x7fffbd422d70,
>     context=0x7fffbd422c40)
>     at /home/gregory/work/64/trunk/working_vm/vm/port/src/signals/linux/signals_common.cpp:107
> #2  <signal handler called>
> #3  0x00002aaabf5254c8 in ?? ()
> The crash happens for me on Gentoo Linux installations both on x86 and x86_64. The easiest
way to reproduce it is to run StackTest from the smoke VM tests.

-- 
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