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 <[EMAIL PROTECTED]> wrote:
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
