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 Fri, 09 Feb 2007 08:14:36 GMT

On 8 February 2007 at 18:04, "Geir Magnusson Jr." <geir@pobox.com> wrote:
> 
> On Feb 8, 2007, at 5:01 PM, 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.
> 
> Can't you just have no-op ports?

Of course, but since we don't really need any of the functions, then
I'd rather we didn't build the library in the first place and that we
fixed the places where the code is referenced.  (Worse, if we did use
the functions, we risk wiping out some of the signal handlers installed
by the VM/JIT.)

Regards,
 Mark.

> > Gregory, why did you want it to be optional?  Do you use this option?
> >
> > Regards,
> >  Mark.
> >
> > 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?


-- 
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