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 Fri, 25 Apr 2008 18:01:56 GMT

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

Ilya Berezhniuk updated HARMONY-5617:

    Attachment: 0001-HARMONY-5617.patch

The patch to fix the problem.

The patch includes following major changes:

1) OS threading was totally moved from VM's HyThread 'os_thread.c' files to static part of
the Port. 'port_thread_create' now creates a thread with special wrapper used to attach the
thread to porting library, i.e. set up TLS data and perform additional preparation. 'port_thread_attach'
function is used to attach threads not created through 'port_thread_create'.

2) When created or foreign thread is attached to the porting library, all the data about stack
location and size and guard pages etc. are stored in TLS, instead of doing this in VM core.
VM core platform-dependent code operating with guard pages/alternative stack/steck overflow
detection etc. was moved to the Port.

3) Port signal/crash handling code was corrected to use Port TLS data. Now it's possible to
detect SO condition in Port itself, and deliver SO (not GPF) to VM on Linux. Also Port can
restore guard page during crash processing, to rethrow signal or exception and perform operation
that need to be done inside of signal/exception handler.

4) Named shared memory is used on both Linux and Windows to synchronize data between multiple
instances of Port static library - the most important thing here is TLS key which must be
the same everywhere.

Some improvements were also made in this patch:
- hand-made assert dialog was enabled to fix the problem with attaching to debugger on Windows/x86_64
- stack settings on Linux/ia64 were synchronized with other platforms; alternative stack now
works on ia64
- crash dump now contains code addresses

---> The patch has intermittent problem with SIGUSR2 handling on Linux (it's used for thread_yield_other)
- I'm investigating the problem now. I hope to update the patch soon with final version.

> [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
>            Assignee: Gregory Shimansky
>            Priority: Minor
>         Attachments: 0001-HARMONY-5617.patch, 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
> Program terminated with signal 11, Segmentation fault.
> #0  0x00002aaaaac27bbf in port_set_longjump_regs (fn=0x2aaaaac2658e, regs=0x7fffbd422b90,
>     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,
>     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.

View raw message