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 Mon, 12 Feb 2007 13:05:53 GMT
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
View raw message