db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Suspectible swallowing of AssertFailure in BTreeScanInfo
Date Thu, 15 Mar 2007 22:21:46 GMT
Mike Matrigali skrev:
> It looks to me like a hack to get around a bug in the caller, ie.
> calling getScanInfo() on a closed conglomerate.
> Usage documentation for GenericScanController.java!close in
> java/engine/org/apache/derby/iapi/store/access/GenericScanController.java
> says that controller should not be used after close().
>
> To my knowledge this interface is only used to print out interesting 
> stuff to runtime statistics, so silently providing as much info as 
> possible was probably considered better than failing a query.   Did
> you run full set of tests and only saw one error - or was that just
> one of many?

Hi Mike,

I think a total of three tests failed when I ran the full test suite. I 
did not print the stack trace for the Throwable then, but all three went 
away when I went back to swallowing the exception.
So I don't think this is major problem, and I will add a comment and 
possibly tighten the catch. This will only affect sane builds anyway. 
I'll also see how deep the code within the try-catch goes and check for 
the "right" assertion error if there are lots of possible error situations.


-- 
Kristian

>
>
>
>
> Kristian Waagan wrote:
>> Hi,
>>
>> Work in the access layer revealed something I find a bit disturbing, 
>> at least with the way the code looks today. In the constructor of 
>> impl.store.access.btree.BTreeScanInfo:
>>
>>         try
>>         {
>>             stat_treeHeight = scan.getHeight();
>>         }
>>         catch (Throwable t)
>>         {
>>             stat_treeHeight = -1;
>>         }
>>
>> I didn't understand why Throwable was caught and ignored, so first I 
>> tried to change it to StandardException. This caused the test 
>> ddlTableLockMode to fail.  I looked at what was going on, and found 
>> this to be thrown from the code above (code modified to print the 
>> Throwable):
>>
>> *** Start: ddlTableLockMode jdk1.5.0_11 2007-03-15 13:53:12 ***
>> 48a49,52
>>  > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED 
>> ControlRow.Get() is being called on a closed container.
>>  > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED 
>> ControlRow.Get() is being called on a closed container.
>>  > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED 
>> ControlRow.Get() is being called on a closed container.
>>  > org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED 
>> ControlRow.Get() is being called on a closed container.
>> Test Failed.
>> *** End:   ddlTableLockMode jdk1.5.0_11 2007-03-15 13:53:21 ***
>>
>> As I said, I find this a bit disturbing. Can anyone with knowledge of 
>> this part of the code shed some light on this?
>>
>> Specifically:
>>  a) Is this expected behavior?
>>  b) Can you add a descriptive comment for the catch block?
>>  c) Should the catch block be more specific, and maybe check for the 
>> expected assert failure?
>>
>>
>>
>> thanks,
>


Mime
View raw message