You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Ivan Volosyuk <iv...@gmail.com> on 2006/09/22 18:22:31 UTC
[classlib][launcher] Signal handler disabling
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?
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [classlib][launcher] Signal handler disabling
Posted by Mark Hindess <ma...@googlemail.com>.
On 8 February 2007 at 18:04, "Geir Magnusson Jr." <ge...@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
> > <gs...@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. <ge...@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. <ge...@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
Re: [classlib][launcher] Signal handler disabling
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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?
>
> 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
> <gs...@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. <ge...@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. <ge...@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
>>
>
> --
> 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
>
>
Re: [classlib][launcher] Signal handler disabling
Posted by Aleksey Ignatenko <al...@gmail.com>.
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 <al...@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 <gs...@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 <al...@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 <ma...@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. <ge...@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
> >
> >
>
Re: [classlib][launcher] Signal handler disabling
Posted by Aleksey Ignatenko <al...@gmail.com>.
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 <gs...@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 <gs...@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 <al...@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 <ma...@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 <gs...@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. <ge...@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. <ge...@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
>
>
Re: [classlib][launcher] Signal handler disabling
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <gs...@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 <al...@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 <ma...@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 <gs...@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. <ge...@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. <ge...@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
Re: [classlib][launcher] Signal handler disabling
Posted by Aleksey Ignatenko <al...@gmail.com>.
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 <gs...@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 <al...@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 <ma...@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 <gs...@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. <ge...@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. <ge...@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
>
>
Re: [classlib][launcher] Signal handler disabling
Posted by Aleksey Ignatenko <al...@gmail.com>.
On 2/13/07, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 12 February 2007 at 14:25, "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.
>
> [I'm not a windows programmer so I don't really understand the details.
> In fact, your "As you know" comment above doesn't really apply to me.
> ;-)]
>
> Correct me if I'm miss understanding you here, but it sounds like you
> implemented minidumps in classlib because it was more convenient rather
> than because it was necessarily the right way to do it. (Of course, it
> might turn out to be the right way to do it but let's discuss it to make
> sure.)
>
> If we continue with the idea of having exception handlers in both
> classlib and drlvm then we need to define a proper interface. Currently
> it is possible (or in fact probable) that there might be a conflict
> between the signal handlers installed by classlib and those installed by
> a VM. For instance, both classlib and the IBM VME install master signal
> handlers, protect signal handler functions with separate(!) monitors and
> keep track separately(!) of which signals the master handler has been
> applied to.
>
> Personally, I think it is better to let the system default handler
> manage signals from the start of execution time until the VM installs a
> master handler. The extra effort of defining a formal interface does
> not seem worth the benefit of having our handler installed slightly
> earlier. And, of course, we have the effort of maintaining two sets of
> exception/signal handling code.
>
> We have to remember that every time we add to the classlib/vm interface
> we are raising the bar for those that might wish to modify their vm to
> run with classlib. This doesn't mean we shouldn't change it but it does
> mean we need to agree that there is real benefit in doing so.
You are right about "you implemented minidumps in classlib because it was
more convenient rather
than because it was necessarily the right way to do it." I integrated
minidump files support into the current exception handling scheme, tried to
discuss it in topic "[launcher][crash handling]Minidump files support on
Windows " and asked questions to classlib gurus if there could be problems
with other VM except drlvm. Minidump files support is the only
superstruction on exception handler to analize and fix stability/reliability
issues. I agree with your arguments on the current exception handling model
therefore in case of changing there I would have to reintegrate minidup
functionality. This was tehchnical solution and I'm ready to admit
assistance to find the right place for it.
> 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.
>
> I'm not really arguing as to whether they be turned on or not. Simply
> about whether we can let it wait and let the VM do it rather than the
> launcher/portlib.
>
> Regards,
> Mark.
>
> P.S. Aleksey, it looks like your mailer makes a mess when quote previous
> messages. For instance, the word 'dump' below should have had an extra
> '> ' but your mailer left it off.
p.s. Sorry for the mess, I suppose I accidentally printed blank there.
> On 2/12/07, Mark Hindess <ma...@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 <gs...@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. <ge...@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. <ge...@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
>
>
> --
> 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
>
>
>
Re: [classlib][launcher] Signal handler disabling
Posted by Gregory Shimansky <gs...@gmail.com>.
Tim Ellison wrote:
> Gregory Shimansky wrote:
>> Mark Hindess wrote:
>>> 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.
>
> I think Mark meant, if it is optional when would you want to have the
> signal hander installed by the launcher?
Hmm I am not sure, maybe it could be used to catch crashes in launcher
itself and porting code which it calls before running the VM. Other than
that I don't see any value in exception handler that is installed by the
launcher.
--
Gregory
Re: [classlib][launcher] Signal handler disabling
Posted by Tim Ellison <t....@gmail.com>.
Gregory Shimansky wrote:
> Mark Hindess wrote:
>> 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.
I think Mark meant, if it is optional when would you want to have the
signal hander installed by the launcher?
Regards,
Tim
Re: [classlib][launcher] Signal handler disabling
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <al...@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 <ma...@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 <gs...@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. <ge...@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. <ge...@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
Re: [classlib][launcher] Signal handler disabling
Posted by Ivan Volosyuk <iv...@gmail.com>.
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.
On 2/12/07, Aleksey Ignatenko <al...@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 <ma...@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 <gs...@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. <ge...@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. <ge...@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
> >
> >
> >
>
--
Ivan
Intel Enterprise Solutions Software Division
Re: [classlib][launcher] Signal handler disabling
Posted by Mark Hindess <ma...@googlemail.com>.
On 12 February 2007 at 14:25, "Aleksey Ignatenko" <al...@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.
[I'm not a windows programmer so I don't really understand the details.
In fact, your "As you know" comment above doesn't really apply to me.
;-)]
Correct me if I'm miss understanding you here, but it sounds like you
implemented minidumps in classlib because it was more convenient rather
than because it was necessarily the right way to do it. (Of course, it
might turn out to be the right way to do it but let's discuss it to make
sure.)
If we continue with the idea of having exception handlers in both
classlib and drlvm then we need to define a proper interface. Currently
it is possible (or in fact probable) that there might be a conflict
between the signal handlers installed by classlib and those installed by
a VM. For instance, both classlib and the IBM VME install master signal
handlers, protect signal handler functions with separate(!) monitors and
keep track separately(!) of which signals the master handler has been
applied to.
Personally, I think it is better to let the system default handler
manage signals from the start of execution time until the VM installs a
master handler. The extra effort of defining a formal interface does
not seem worth the benefit of having our handler installed slightly
earlier. And, of course, we have the effort of maintaining two sets of
exception/signal handling code.
We have to remember that every time we add to the classlib/vm interface
we are raising the bar for those that might wish to modify their vm to
run with classlib. This doesn't mean we shouldn't change it but it does
mean we need to agree that there is real benefit in doing so.
> 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.
I'm not really arguing as to whether they be turned on or not. Simply
about whether we can let it wait and let the VM do it rather than the
launcher/portlib.
Regards,
Mark.
P.S. Aleksey, it looks like your mailer makes a mess when quote previous
messages. For instance, the word 'dump' below should have had an extra
'> ' but your mailer left it off.
> On 2/12/07, Mark Hindess <ma...@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 <gs...@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. <ge...@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. <ge...@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
--
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
Re: [classlib][launcher] Signal handler disabling
Posted by Aleksey Ignatenko <al...@gmail.com>.
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 <ma...@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 <gs...@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. <ge...@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. <ge...@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
>
>
>
Re: [classlib][launcher] Signal handler disabling
Posted by Mark Hindess <ma...@googlemail.com>.
On 12 February 2007 at 10:27, "Aleksey Ignatenko" <al...@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 <gs...@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 <gs...@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. <ge...@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. <ge...@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
Re: [classlib][launcher] Signal handler disabling
Posted by Aleksey Ignatenko <al...@gmail.com>.
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.
Aleksey.
On 2/9/07, Gregory Shimansky <gs...@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 <gs...@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. <ge...@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. <ge...@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
>
>
Re: [classlib][launcher] Signal handler disabling
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <gs...@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. <ge...@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. <ge...@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
Re: [classlib][launcher] Signal handler disabling
Posted by Mark Hindess <ma...@googlemail.com>.
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?
Regards,
Mark.
On 10 January 2007 at 21:07, Gregory Shimansky <gs...@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. <ge...@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. <ge...@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
>
--
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
Re: [classlib][launcher] Signal handler disabling
Posted by Gregory Shimansky <gs...@gmail.com>.
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. <ge...@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. <ge...@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
Re: [classlib][launcher] Signal handler disabling
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Just curious - how where is it causing you pain?
By causing a conflict with the handler that the VM/JIT wants to install
for it's own use.
Regards,
Tim
Re: [classlib][launcher] Signal handler disabling
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Just curious - how where is it causing you pain?
geir
On Jan 10, 2007, at 12:16 PM, 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.
>
> Regards,
> Tim
>
> 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. <ge...@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. <ge...@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
>>
>>
Re: [classlib][launcher] Signal handler disabling
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 10, 2007, at 12:16 PM, 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
geir
>
> Regards,
> Tim
>
> 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. <ge...@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. <ge...@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
>>
>>
Re: [classlib][launcher] Signal handler disabling
Posted by Ivan Volosyuk <iv...@gmail.com>.
At last!
+1!
--
Ivan
On 1/10/07, Tim Ellison <t....@gmail.com> 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.
>
> Regards,
> Tim
>
> 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. <ge...@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. <ge...@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?
Re: [classlib][launcher] Signal handler disabling
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Thanks. On it..
geir
On Jan 11, 2007, at 7:53 AM, Tim Ellison wrote:
> Done in r495209.
>
> I tweaked the launcher in the classlib/luni subdir for now, even
> though
> I realize this code is destined to move to jdktools. This way the
> move
> is a straight copy from classlib -> jdktools rather than have to fuss
> about merging from both.
>
> Regards,
> Tim
>
> 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.
>>
>> Regards,
>> Tim
>>
>> 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. <ge...@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. <ge...@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
>>>
>>>
>>
Re: [classlib][launcher] Signal handler disabling
Posted by Tim Ellison <t....@gmail.com>.
Done in r495209.
I tweaked the launcher in the classlib/luni subdir for now, even though
I realize this code is destined to move to jdktools. This way the move
is a straight copy from classlib -> jdktools rather than have to fuss
about merging from both.
Regards,
Tim
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.
>
> Regards,
> Tim
>
> 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. <ge...@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. <ge...@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
>>
>>
>
Re: [classlib][launcher] Signal handler disabling
Posted by Tim Ellison <t....@gmail.com>.
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.
Regards,
Tim
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. <ge...@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. <ge...@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
>
>
Re: [classlib][launcher] Signal handler disabling
Posted by Ivan Volosyuk <iv...@gmail.com>.
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. <ge...@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. <ge...@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
Re: [classlib][launcher] Signal handler disabling
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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. <ge...@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
>
---------------------------------------------------------------------
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
Re: [classlib][launcher] Signal handler disabling
Posted by Ivan Volosyuk <iv...@gmail.com>.
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. <ge...@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
Re: [classlib][launcher] Signal handler disabling
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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?
>
> --
> Ivan
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
Re: [classlib][launcher] Signal handler disabling
Posted by Aleksey Ignatenko <al...@gmail.com>.
BTW, to stop in the palces where crash happent (before crash is handled by
crash handler) in MS debugger one need to set all kinds of exceptions in
Debug/Exceptions (in MS VisualStudio) to "Break into the debugger when
exception is thrown".
Aleksey.
On 9/22/06, Ivan Volosyuk <iv...@gmail.com> 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?
>
> --
> Ivan
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> 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
>
>