From dev-return-24247-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Feb 13 09:37:28 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 85675 invoked from network); 13 Feb 2007 09:37:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Feb 2007 09:37:27 -0000 Received: (qmail 10310 invoked by uid 500); 13 Feb 2007 09:37:31 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 10283 invoked by uid 500); 13 Feb 2007 09:37:31 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 10274 invoked by uid 99); 13 Feb 2007 09:37:31 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Feb 2007 01:37:31 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of aleksey.ignatenko@gmail.com designates 64.233.184.230 as permitted sender) Received: from [64.233.184.230] (HELO wr-out-0506.google.com) (64.233.184.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Feb 2007 01:37:21 -0800 Received: by wr-out-0506.google.com with SMTP id i21so1833429wra for ; Tue, 13 Feb 2007 01:37:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=L9yf0Z0CRlgzKQ5xjayLakOI7HjWTCEiTOWPg/6bmyh4fnWw4S0X5FkidDc4zeCMEiRjhCOfg4mncczuEPeoOG2NXUKdSDcKeXxl9sI7UQWhMLPd9dUaLgIQ6h1sF8ahEe+ZACsjac/SdkIou0AJPsdI65HlYmw2jbbUFtNGMHE= Received: by 10.114.152.17 with SMTP id z17mr7476431wad.1171359418426; Tue, 13 Feb 2007 01:36:58 -0800 (PST) Received: by 10.114.156.8 with HTTP; Tue, 13 Feb 2007 01:36:58 -0800 (PST) Message-ID: <5836de490702130136n56e6bc1dx8cd3ce255ced2e20@mail.gmail.com> Date: Tue, 13 Feb 2007 15:36:58 +0600 From: "Aleksey Ignatenko" To: dev@harmony.apache.org Subject: Re: [classlib][launcher] Signal handler disabling In-Reply-To: <200702130833.l1D8Xw24027289@d12av04.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_46311_28312927.1171359418346" References: <12385bbd0609220922t38d1c155o41eabc6ee41daa12@mail.gmail.com> <12385bbd0609221208u408ba476ue3dc64d9ca7a0a1d@mail.gmail.com> <45A51F65.9050507@gmail.com> <200702082201.l18M1GTK025048@d12av03.megacenter.de.ibm.com> <5836de490702112027o677fedd1m5a55f09bef992bda@mail.gmail.com> <200702120803.l1C83eH7032335@d06av01.portsmouth.uk.ibm.com> <5836de490702120025j1e118a70qb266b8e8a5292cbd@mail.gmail.com> <200702130833.l1D8Xw24027289@d12av04.megacenter.de.ibm.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_46311_28312927.1171359418346 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 2/13/07, Mark Hindess 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 wrote: > > > > > > > > > On 12 February 2007 at 10:27, "Aleksey Ignatenko" < > > > aleksey.ignatenko@gmail.com> wrote: > > > > > > > > Gregory, please look at > > > > *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 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. 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. 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 > > > ------=_Part_46311_28312927.1171359418346--