Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4C4087E7.7020006@sbcglobal.net>
Date: Fri, 16 Jul 2010 09:25:11 -0700
From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: instability in AccessTest?
References: <19519.10660.347690.571644@gargle.gargle.HOWL>
	<AANLkTinw3YgTVPzrjJgBgUgHFI1TYAF7SXqao-TDDKWt@mail.gmail.com>
 <x1ox4og0gmwu.fsf@oracle.com>
In-Reply-To: <x1ox4og0gmwu.fsf@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  On 7/15/2010 7:50 PM, Dag H. Wanvik wrote:
> Looking at the stack trace again, it seems this happens because we are
> trying to save a copy of the generated class file here:
>
> DatabaseClasses#loadGeneratedClass:
>          :
>      		} catch (VirtualMachineError vme) { // these may be beyond saving, but fwiw
>
> 			    WriteClassFile(fullyQualifiedName, classDump, vme);
>
> Normally we don't try to write the generated classfile to disk, so
> that's why we see the security exception, I presume.
>
> The Javadoc for VirtualMachineError says:
>
> "Thrown to indicate that the Java Virtual Machine is broken or has run
> out of resources necessary for it to continue operating. "
>
> so maybe my machine was out of resources.
>
>
It seems when a permission error occurs on the write, we lose the 
VirtualMachineError.    It seems we need a priv block for  
WriteClassFile.  Then if we still get a permissions error,  we should 
make sure the VirtualMachineError is the one thrown or use initCause() 
to get both exceptions.  I would think also the permissions to dump the 
class in such dire circumstances should be documented.  I guess it would 
be optional but highly recommended.