Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <18879396.1200033694168.JavaMail.jira@brutus>
Date: Thu, 10 Jan 2008 22:41:34 -0800 (PST)
From: "Alexey Varlamov (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-5379) [drlvm][signals] Several crash
 handler improvements
In-Reply-To: <23778088.1199990494126.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-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557917#action_12557917 ] 

Alexey Varlamov commented on HARMONY-5379:
------------------------------------------

Well done Ilya, thanks for improving this area! A few observations:
1) what about renaming "port_filepath_short_name" -> "port_filepath_basename", which is more intuitive and less confusing.
2) Even if a name does not fit to a buffer, "too short buffer" message is not helpful. More reasonable to truncate the name and just add some indication of truncation, smth like "a_very_loooo...".
3) No reason to use platform suffix in source filename: stack_dump_linux.cpp / stack_dump_win.cpp if they reside in specific folders like  vmcore/src/util/linux/ .

> [drlvm][signals] Several crash handler improvements
> ---------------------------------------------------
>
>                 Key: HARMONY-5379
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5379
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>         Environment: All
>            Reporter: Ilya Berezhniuk
>         Attachments: H-5379.patch
>
>
> Together with unifying signal handlers in HARMONY-5366, I've made some improvements in crash handler.
> The patch is in attachment.
> Following features were added:
> - when one thread is in crash handler, other threads are blocked to prevent from printing several stack traces
> - processor registers are now printed on Linux also
> - analysis of crashed address:
>     - a module containing crashed address is identified
>     - detected module kind: VM module / JNI library / other
>     - if crash address does not belong to any module, containing memory region is identified; access information is provided
> - the whole table of loaded modules is printed
> - the list of threads registeret to VM is printed with crashed thread marked
> - heap usage in crash handler was reduced to be sure that at least some kind of info will be printed (if global heap lock is not released)
> I'm also working on some new heuristics to improve native stack unwinding on x86_64, but this work is not finished yet, so I'll prove it in additional patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.