harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Ignatenko" <aleksey.ignate...@gmail.com>
Subject Re: [classlib][launcher] Signal handler disabling
Date Wed, 14 Feb 2007 04:58:18 GMT
ok, I see the whole picture now. And I want to conclude on minidumps support
(though it should be done in another topic :)):
try to move it to drlvm (generate minidump files additionally to stack trace
on the basis of the drlvm exception handler) to be independent from classlib
(as classlib affects not only drlvm). I'll continue experimenting with it.

Thanks everyone,
Aleksey.

On 2/13/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message