[squeak-dev] Re: Bug in BytecodeGenerator>>#jump:if:

nice ncellier at ifrance.com
Sun Jun 22 15:16:37 UTC 2008


Klaus D. Witzel wrote:
> On Sun, 22 Jun 2008 16:05:57 +0200, Nicolas wrote:
> 
>> nice wrote:
>>> Hello André,
>>>  Good find!
>>> I confirm only 4 bytes codes are reserved for longJumpIfFalse and 4 
>>> bytes code for longJumpIfTrue.
>>> So this seems like a MAJOR bug. The kind of bug able to crash squeak 
>>> if you generate and execute a method with a jump > 1024 and < 2048...
>>>
>>
>> Just for the fun of it: how do you write non regression tests for such 
>> ones?
>>
>> self shouldnt: [SmalltalkImage crash] ???
> 
> You might want to check the CompiledMethod of the following method (the 
> bytecode which in my .image has offset 34):
> 
> !UndefinedObject methodsFor: 'as yet unclassified' stamp: 'kwl 6/22/2008 
> 16:37'!
> longJumpIfFalseTest
>     "(nil class>>#longJumpIfFalseTest) inspect"
> 
>     true ifTrue:[
>         {42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42. 42.
>         42. 42. 42. 42. 42. 42
>         }
>     ]! !
> 
> /Klaus
> 
>>

Thanks Klaus, i know how to generate the bug - believe me, I'm really 
good at generating bugs :)

My problem is with the quality dogma: "provide a test that fails before 
the patch and pass after".

So what would you assert about longJumpIfFalseTest?

We could assert that trying to compile such a method should raise an 
Exception (let's say a ByteCodeLimitException).
But if we install a handler that overcome the limitation (like compiling 
above example using a BlockClosure, true ifTrue: [aBlock value]) the 
test would not raise the ByteCodeLimitException and thus would fail! 
This would not be a very good test...

A better test should be to try and compile, and if it compiles to assert 
the result. And if the result is a crash then...

	self shouldnt: [...] raise: SmalltalkImageCrash.

Ah Ah, would i be the maintainer of an image containing this bug, that i 
would not wait for a non regression test. I would correct it as quickly 
as possible.

If a good non regression tests comes, that's a plus, I take it. But 
should never be a dogma. Just take a look at 
http://bugs.squeak.org/view.php?id=6584 i bet the bug still is in the 
latests images.

Nicolas




More information about the Squeak-dev mailing list