harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib][launcher] Signal handler disabling
Date Mon, 12 Feb 2007 08:03:40 GMT

On 12 February 2007 at 10:27, "Aleksey Ignatenko" <aleksey.ignatenko@gmail.com> wrote:
> 
> Gregory, please look at
> *HARMONY-3124*<https://issues.apache.org/jira/browse/HARMONY-3124>(Generation
> of minidumps files on crash). This is about generating minidump
> files on the basis of crash handler in launcher. Minidump is similar to dump
> file on linux. There is much more possibilities to analize the problem with
> it.

This could be handled in the VM signal handler code though?  So while
think these minidump could be very useful, I'm not sure this is a reason
to have a classlib signal handler.

-Mark.

> On 2/9/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> >
> > Mark Hindess wrote:
> > > I think we should go for the record of resurrecting a thread the most
> > > times ;-)
> > >
> > > The current solution still compiles the hysig code.  However, I've
> > > got a patch (windows and Linux but only tested on Linux) that adds a
> > > flag to give the option to avoid the compilation of the hysig library
> > > completely.  The default is to compile it but I'd actually like to
> > > reverse that after some wider testing.
> > >
> > > Does this seem reasonable?
> > >
> > > I want to use this option because it means I can avoid porting the
> > > signalling code to new architectures and platforms until we decide if we
> > > are going to keep it.  At the moment, I think we probably should get rid
> > > of it and let the VM handle signals.
> > >
> > > Gregory, why did you want it to be optional?  Do you use this option?
> >
> > The reason is quite simple. When VM crashes it is much easier to debug
> > it right at the spot of the crash. On Windows it is done with Just In
> > Time debugging facility, on Linux core dump is useful. DRLVM with can
> > and does detect the condition when crash happens inside of VM and when
> > it is ran with -XDassert_dialog=true (default) does not try to do
> > anything intelligent like printing stack. This allows debugging at the
> > spot of the crash.
> >
> > When launcher installs its own handler it catches the crash. Even though
> > it can print registers and maybe some stack symbols, it is not as good
> > as using full fledged debugger to analyze the problem.
> >
> > > On 10 January 2007 at 21:07, Gregory Shimansky <gshimansky@gmail.com>
> > wrote:
> > >> Tim Ellison wrote:
> > >>> I'm going for the record of resurrecting the oldest thread ;-)
> > >>>
> > >>> Having this additional signal handler in the launcher is causing me
> > pain
> > >>> too, so unless there are objections now I'm going to go ahead and
> > >>> disable it by default, and have an option to enable it for those that
> > want.
> > >> +1
> > >>
> > >> Let's have it optional.
> > >>
> > >>> Ivan Volosyuk wrote:
> > >>>> It seems that in cmain.c in function genericSignalHandler() just
> > >>>> removing abort() statement will cause default system handler to
> > >>>> execute pointing the exact place of fault right after printing
all
> > >>>> this useless crash info. I have no idea how to obtain property
value
> > >>>> in this place to make the abort() conditional. Anyway, I think
it
> > >>>> would be much beneficial for developers to have crash by default.
> > >>>> --
> > >>>> Ivan
> > >>>>
> > >>>> On 9/22/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >>>>> This can't be that hard.  Maybe a simple command-line flag
> > >>>>>
> > >>>>>    -launcher:something
> > >>>>>
> > >>>>> Give it a wack and see what happens...
> > >>>>>
> > >>>>> geir
> > >>>>>
> > >>>>>
> > >>>>> On Sep 22, 2006, at 1:29 PM, Ivan Volosyuk wrote:
> > >>>>>
> > >>>>>> Exactly. I would like to have a way to disable the crash
handler
> > >>>>>> invoked in the call.
> > >>>>>> It is quite painful to locate crashing place when the crash
handler
> > >>>>>> enabled. Even setting breakpoint in the handler doesn't
help -
> > stack
> > >>>>>> at this place has number of system frames without debug
information
> > >>>>>> which hide the actual problematic point.
> > >>>>>> --
> > >>>>>> Ivan
> > >>>>>>
> > >>>>>> On 9/22/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >>>>>>> Do you mean sig_protect in cmain.c?
> > >>>>>>>
> > >>>>>>> geir
> > >>>>>>>
> > >>>>>>> On Sep 22, 2006, at 12:22 PM, Ivan Volosyuk wrote:
> > >>>>>>>
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> While working on windows on DRLVM I introduced
some crash
> > >>>>>>> situation. I
> > >>>>>>>> found out that there are two active crash handlers.
One in
> > >>>>>>> DRLVM, the
> > >>>>>>>> other in launcher/classlib.
> > >>>>>>>>
> > >>>>>>>> I can disable DRLVM's one: -Dvm.assert_dialog=1
> > >>>>>>>> But the launcher's crash handler still prevent
me to use
> > >>>>>>> debugger to
> > >>>>>>>> locate exact place of access violation in VM code.
Is it
> > >>>>>>> possible to
> > >>>>>>>> disable it somehow?
> > >>>> ---------------------------------------------------------------------
> > >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > >>>> For additional commands, e-mail:
> > harmony-dev-help@incubator.apache.org
> > >>>>
> > >>>>
> > >>
> > >> --
> > >> Gregory
> > >>
> > >
> >
> >
> > --
> > Gregory
> >
> >
> 
> ------=_Part_30943_21988286.1171254458336--
> 

-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Mime
View raw message