[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
|