Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <1534760295.1206443608200.JavaMail.jira@brutus>
Date: Tue, 25 Mar 2008 04:13:28 -0700 (PDT)
From: "Gregory Shimansky (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-5617) [drlvm] On Linux crash handler may
 crash itself when handling SOE condition
In-Reply-To: <1428895466.1205925026285.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Gregory Shimansky updated HARMONY-5617:
---------------------------------------


I applied this workaround at 640769 and indeed SOE tests now passed. The bug remains open until a better solution is implemented.

> [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: 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.