On 12 February 2007 at 10:27, "Aleksey Ignatenko" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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. <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > >>>> For additional commands, e-mail: > > [EMAIL PROTECTED] > > >>>> > > >>>> > > >> > > >> -- > > >> 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
