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 Tue, 13 Feb 2007 05:43:17 GMT
Forgot to say, I don't mind from disabling of launcher's exception handler
in default mode, but I'm for having an option to switch it on.

Aleksey.

On 2/13/07, Aleksey Ignatenko <aleksey.ignatenko@gmail.com> 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.
>
> Aleksey.
>
>  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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message