Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: error (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <200702082201.l18M1GTK025048@d12av03.megacenter.de.ibm.com>
References: <12385bbd0609220922t38d1c155o41eabc6ee41daa12@mail.gmail.com>
 <392CE86F-333E-479E-9525-25BDF12E470F@pobox.com>
 <12385bbd0609221029l7763d60bi29bcc6f184bb7391@mail.gmail.com>
 <448CD2A0-8032-4711-81D3-3BC97D831444@pobox.com>
 <12385bbd0609221208u408ba476ue3dc64d9ca7a0a1d@mail.gmail.com>
 <45A51F65.9050507@gmail.com> <eo3a1q$kfe$1@sea.gmane.org>
 <200702082201.l18M1GTK025048@d12av03.megacenter.de.ibm.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <138BFE78-F37C-4CAC-A1A2-FF886F6A2828@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: [classlib][launcher] Signal handler disabling 
Date: Thu, 8 Feb 2007 18:04:00 -0500
To: dev@harmony.apache.org


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  
> <gshimansky@gmail.com> wrote:
>> Tim Ellison wrote:
>>> I'm going for the record of resurrecting the oldest thread ;-)
>>>
>>> Having this additional signal handler in the launcher is causing  
>>> me pain
>>> too, so unless there are objections now I'm going to go ahead and
>>> disable it by default, and have an option to enable it for those  
>>> that want.
>>
>> +1
>>
>> Let's have it optional.
>>
>>> Ivan Volosyuk wrote:
>>>> It seems that in cmain.c in function genericSignalHandler() just
>>>> removing abort() statement will cause default system handler to
>>>> execute pointing the exact place of fault right after printing all
>>>> this useless crash info. I have no idea how to obtain property  
>>>> value
>>>> in this place to make the abort() conditional. Anyway, I think it
>>>> would be much beneficial for developers to have crash by default.
>>>> -- 
>>>> Ivan
>>>>
>>>> On 9/22/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>>>> This can't be that hard.  Maybe a simple command-line flag
>>>>>
>>>>>    -launcher:something
>>>>>
>>>>> Give it a wack and see what happens...
>>>>>
>>>>> geir
>>>>>
>>>>>
>>>>> On Sep 22, 2006, at 1:29 PM, Ivan Volosyuk wrote:
>>>>>
>>>>>> Exactly. I would like to have a way to disable the crash handler
>>>>>> invoked in the call.
>>>>>> It is quite painful to locate crashing place when the crash  
>>>>>> handler
>>>>>> enabled. Even setting breakpoint in the handler doesn't help -  
>>>>>> stack
>>>>>> at this place has number of system frames without debug  
>>>>>> information
>>>>>> which hide the actual problematic point.
>>>>>> --
>>>>>> Ivan
>>>>>>
>>>>>> On 9/22/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>>>>>> Do you mean sig_protect in cmain.c?
>>>>>>>
>>>>>>> geir
>>>>>>>
>>>>>>> On Sep 22, 2006, at 12:22 PM, Ivan Volosyuk wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> While working on windows on DRLVM I introduced some crash
>>>>>>> situation. I
>>>>>>>> found out that there are two active crash handlers. One in
>>>>>>> DRLVM, the
>>>>>>>> other in launcher/classlib.
>>>>>>>>
>>>>>>>> I can disable DRLVM's one: -Dvm.assert_dialog=1
>>>>>>>> But the launcher's crash handler still prevent me to use
>>>>>>> debugger to
>>>>>>>> locate exact place of access violation in VM code. Is it
>>>>>>> possible to
>>>>>>>> disable it somehow?
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> 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
>
>