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 evgueni.brevnov@gmail.com
 designates 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=piUuS/RDKQvXfqqlG8y5LOunuiXqPN89wYBYXLzpFCy+gt2PG7GF4clxSkmppSsYBzHAJhihco4PsNHhgV0v7o1I9gEjJ5HXhlD8RzAfJ/P66r9kw24wI8iu/HIwov/fv7IFabIBCKiQ2qB2MC15/SVacmjUf38sjfsdmWmq0Ks=
Message-ID: <e29119980611300628v6ec1a96bgb7beb3699a68f62e@mail.gmail.com>
Date: Thu, 30 Nov 2006 20:28:10 +0600
From: "Evgueni Brevnov" <evgueni.brevnov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: svn commit: r479802 -
 /harmony/enhanced/drlvm/trunk/vm/vmcore/src/util/win/ia32/nt_exception_filter.cpp
In-Reply-To: <ekmp7h$pkj$1@sea.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061127232350.C95671A9846@eris.apache.org>
	 <ekhel2$vgn$1@sea.gmane.org> <ekhhfh$bjj$1@sea.gmane.org>
	 <ekhht9$cgq$1@sea.gmane.org> <456C58EA.1080908@pobox.com>
	 <ekhs4n$ks0$1@sea.gmane.org>
	 <e29119980611282102n56ba22eap2a3ade54ae08670d@mail.gmail.com>
	 <456DBBF8.1050604@pobox.com>
	 <e29119980611300559k76f0718aw90da90eea6cb4721@mail.gmail.com>
	 <ekmp7h$pkj$1@sea.gmane.org>

On 11/30/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> Evgueni Brevnov wrote:
> > Let's leave the -D or -X dilemma for a while. Nina Rinskya and me
> > found more serious problem. The problem is that debug windows popups
> > even if -Dvm.assert_dialog=false is specified. It happens because each
> > dll has its own copy of the variable which controls the behaviour of
> > an assert macro. In other words when you change the report mode by
> > calling _CrtSetReportMode it affect the current dll only. So if
> > assertion fails in any other dll we will see debug window.
> >
> > Any ideas how to fix that?
>
> A question, just to verify understanding:
>
> does portlib-style signal catching, which is done in launcher,
> misses these application errors too?

Yes it does. When assert fails it creates debug window explicitly. So
there is no connection between exception handlers and assert
statements.

>
> I was under impression that stock version of launcher does not allow
> any uncaught exception to slip through.

No exception is generated if assert fails....

>
>