harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [classlib][launcher] Signal handler disabling
Date Tue, 13 Feb 2007 13:48:01 GMT
Aleksey Ignatenko wrote:
> Good point, Gregory. I like the idea distinguishing release and debug
> modes for different audience with appropriate reaction to crashes.
> But I would also add that working exception handler in launcher is 
> necessary
> for long lasting scenarios like EUT or some other being run under CC which
> are used to find regressions and improve VM stability. Absence of exception
> handler in launcher leads to interactive behaviour of such scenario like
> stopping on Debug window and waiting actions from user. In addition dump
> files would significantly simplify analysis of happent crashes.

The interactive window appears because DRLVM current exception handler 
doesn't recognize -XDassert_dialog=false. This is a regression. When 
this problem is fixed, VM handler will try to print native/Java stack 
traces instead of showing the debugging dialog.

So this is not related to launcher being able to handle exceptions on 
its own or not.

> On 2/12/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>>
>> Ivan Volosyuk wrote:
>> > I think the main audience here is developers. So, let us concentrate
>> > on the convenience for developers. When we have stable binary releases
>> > those crash dumps may become useful, but not right now when we have
>> > people working mostly on latest SVN version.
>>
>> I'd like to add one more choice. We have two modes of compilation. The
>> default is debug which is useful for development. In this mode I think
>> minidumps should be turned off.
>>
>> But binary snapshots are built in release and are useful for people who
>> don't want to work with sources. In this mode we could have minidump
>> mode to be the default but with an option to turn them off because
>> debugging release code is sometimes necessary.
>>
>> > On 2/12/07, Aleksey Ignatenko <aleksey.ignatenko@gmail.com> wrote:
>> >> I experimented with minidumps on drlvm exception handler some time ago
>> >> and
>> >> could make it working. The problem is that minidump functionality
>> >> (dbghelp
>> >> library) as it described in documentation is fully supported by
>> >> structured
>> >> exception handler, but I had problems with vectored exception handler
>> >> (which
>> >> is in drlvm) ptinting stack of main thread (where exception happent).
>> >> As you
>> >> know there is structured exception handler in launcher, therefore I
>> >> succeded
>> >> to realize minidumps support there.
>> >>
>> >> My opinion, is that default mode should have exception handler in
>> >> classlib
>> >> turned on with dump files support. Default mode is a mode of users, in
>> >> case
>> >> of crash anyone should be able to send dump file to developers for
>> >> analysis.
>> >> And developers should use special flags to handle crashes with
>> debugger.
>> >>
>> >>
>> >> On 2/12/07, Mark Hindess <mark.hindess@googlemail.com> wrote:
>> >> >
>> >> >
>> >> > 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
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>>
>> -- 
>> Gregory
>>
>>
> 


-- 
Gregory


Mime
View raw message