Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Gregory Shimansky <gshimansky@gmail.com>
Subject: Re: [drlvm][classlib unit tests] iterative runs
Date: Fri, 24 Nov 2006 05:05:45 +0300
Lines: 48
Message-ID: <ek5k1t$ta8$1@sea.gmane.org>
References: <678b3f320611210606w61cb787r157efd4ad941735d@mail.gmail.com>
 <c30d70960611211602t640f94bbkb70a981cd5b79ce9@mail.gmail.com>
 <200611240019.59711.gshimansky@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
In-Reply-To: <200611240019.59711.gshimansky@gmail.com>
Sender: news <news@sea.gmane.org>

Correction below

Gregory Shimansky wrote:
> On Wednesday 22 November 2006 03:02 Alexei Fedotov wrote:
>> Tatiana,
>> That's great! Feel free to file JIRA issues about new problems.
>>
>> This is quite interesting that you haven't discovered
>> org.apache.harmony.logging.tests.java.util.logging.SocketHandlerTest
>> failure using effectively the same revision as I.  This makes me think
>> that my problems can be local to my computer.
> 
> The problem with this test appeared to be a regression after HARMONY-2006. 
> DRLVM started to halt of all unknown exceptions passing to VEH handler 
> when -Dvm.assert_dialog=true. This is quite wrong thing to do because VEH 
> handler is called in case of C++ exceptions too.
> 
> Also it appeared that windows kernel uses exceptions inside of itself, so VEH 
> handler is called for some API functions which return an error, like in case 
> of SocketHandlerTest. Previous to HARMONY-2006 [1] VM didn't react to any 
> unknown codes, just returned EXCEPTION_CONTINUE_EXECUTION from the handler. 

It should have been "EXCEPTION_CONTINUE_SEARCH" in this text, I pasted a 
wrong one from the code. This code was used to find a suitable handler 
(or show the error window) for the received exception.

> Now it started to call DebugBreak in case when 
> UnhandledExceptionFilter(nt_exception) == EXCEPTION_CONTINUE_SEARCH.
> 
> Ivan offered a quick fix in HARMONY-2285, which calls this function only if 
> IS_ERROR [2] macro returns true for the exception code. The fix helped, and 
> now in interactive test runs when -Dvm.assert_dialog=true (default) tests 
> pass just as well as in non-interactive mode.
> 
> I am still a bit unsure, why mess around with unknown exception codes, maybe 
> it is better to return EXCEPTION_CONTINUE_SEARCH always, and the debugging 
> dialog will be open by the default NT handler.
> 
> [1] 
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp?p2=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&p1=%2Fincubator%2Fharmony%2Fenhanced%2Fdrlvm%2Ftrunk%2Fvm%2Fvmcore%2Fsrc%2Futil%2Fwin%2Fia32%2Fnt_exception_filter.cpp&r1=476183&r2=476182&view=diff&pathrev=476183
> 
> [2] 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/74497f4b-1c88-4c8a-b9e7-606e77364f48.asp
> 


-- 
Gregory