Compiler+Decompiler together have a serious 'bad case' bug

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiler+Decompiler together have a serious 'bad case' bug

Klaus D. Witzel
http://bugs.impara.de/view.php?id=2921

You can provoke the emergency console by having Decompiler fail with self  
error:'bad case' in #send:super:numargs.

The following trivial, innocent looking code snippet does it in 3.8 and  
3.9:

| x y |
  x := y := 0.
{'a'. 'b'. 'c'} do: [:c|
     (c string halt; endsWith: 'd')
         ifTrue: [x:= 1 + x]
         ifFalse: [y:= 1 + y]]

Strange, why should Decompiler be involved in a halt situation, and then,  
why should it refuse to decompile code?

/Klaus


Reply | Threaded
Open this post in threaded view
|

Re: Compiler+Decompiler together have a serious 'bad case' bug

Klaus D. Witzel
Sorry, hyperlink is

- http://bugs.impara.de/view.php?id=4313

/Klaus

On Sat, 22 Jul 2006 23:37:07 +0200, Klaus D. Witzel  
<[hidden email]> wrote:

> http://bugs.impara.de/view.php?id=2921
>
> You can provoke the emergency console by having Decompiler fail with  
> self error:'bad case' in #send:super:numargs.
>
> The following trivial, innocent looking code snippet does it in 3.8 and  
> 3.9:
>
> | x y |
>   x := y := 0.
> {'a'. 'b'. 'c'} do: [:c|
>      (c string halt; endsWith: 'd')
>          ifTrue: [x:= 1 + x]
>          ifFalse: [y:= 1 + y]]
>
> Strange, why should Decompiler be involved in a halt situation, and  
> then, why should it refuse to decompile code?
>
> /Klaus
>
>
>



Reply | Threaded
Open this post in threaded view
|

[FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

Bert Freudenberg-3
Simpler test case - in a Browser, add this method:

test
        (self foo; bar)
                ifTrue: [1]
                ifFalse: [2]

Then switch to "decompile" instead of "source".

If the receiver of an ifTrue:ifFalse: is a cascade, the decompiler  
mistakes it for a case statement. I attached a fix for that, could  
someone please verify?

- Bert -


Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:

> Sorry, hyperlink is
>
> - http://bugs.impara.de/view.php?id=4313
>
> /Klaus
>
> On Sat, 22 Jul 2006 23:37:07 +0200, Klaus D. Witzel  
> <[hidden email]> wrote:
>
>> http://bugs.impara.de/view.php?id=2921
>>
>> You can provoke the emergency console by having Decompiler fail  
>> with self error:'bad case' in #send:super:numargs.
>>
>> The following trivial, innocent looking code snippet does it in  
>> 3.8 and 3.9:
>>
>> | x y |
>>   x := y := 0.
>> {'a'. 'b'. 'c'} do: [:c|
>>      (c string halt; endsWith: 'd')
>>          ifTrue: [x:= 1 + x]
>>          ifFalse: [y:= 1 + y]]
>>
>> Strange, why should Decompiler be involved in a halt situation,  
>> and then, why should it refuse to decompile code?
>>
>> /Klaus
>>
>>
>>
>
>
>





decompileCascade-bf.1.cs.gz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Compiler+Decompiler together have a serious 'bad case' bug

Bert Freudenberg-3
In reply to this post by Klaus D. Witzel
Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:

> Strange, why should Decompiler be involved in a halt situation

I guess because there is no method source if you evaluate the code in  
a workspace.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Compiler+Decompiler together have a serious 'bad case' bug

Marcus Denker

On 23.07.2006, at 16:31, Bert Freudenberg wrote:

> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>
>> Strange, why should Decompiler be involved in a halt situation
>
> I guess because there is no method source if you evaluate the code  
> in a workspace.
>

Printing of blocks for the stack-trace shown in the pre-debug window  
nees the
decompiler...

     Marcus




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Compiler+Decompiler together have a serious 'bad case' bug

Klaus D. Witzel
On Sun, 23 Jul 2006 16:52:01 +0200, Marcus Denker <[hidden email]>  
wrote:
> On 23.07.2006, at 16:31, Bert Freudenberg wrote:
>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>
>>> Strange, why should Decompiler be involved in a halt situation
>>
>> I guess because there is no method source if you evaluate the code
>> in a workspace.

Good guess but I found the error in a regular .changes file source coded  
method.

> Printing of blocks for the stack-trace shown in the pre-debug window
> nees the
> decompiler...

Strange, all source code is available.

>      Marcus
>



Reply | Threaded
Open this post in threaded view
|

Re: [FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

Klaus D. Witzel
In reply to this post by Bert Freudenberg-3
It works, your and my example no longer fail.

Is there a routine to check the modified Decompiler against all source  
coded methods?

/Klaus

On Sun, 23 Jul 2006 16:23:31 +0200, Bert Freudenberg wrote:

> Simpler test case - in a Browser, add this method:
>
> test
> (self foo; bar)
> ifTrue: [1]
> ifFalse: [2]
>
> Then switch to "decompile" instead of "source".
>
> If the receiver of an ifTrue:ifFalse: is a cascade, the decompiler
> mistakes it for a case statement. I attached a fix for that, could
> someone please verify?
>
> - Bert -
>
>
> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>
>> Sorry, hyperlink is
>>
>> - http://bugs.impara.de/view.php?id=4313
>>
>> /Klaus
>>
>> On Sat, 22 Jul 2006 23:37:07 +0200, Klaus D. Witzel
>> <[hidden email]> wrote:
>>
>>> http://bugs.impara.de/view.php?id=2921
>>>
>>> You can provoke the emergency console by having Decompiler fail
>>> with self error:'bad case' in #send:super:numargs.
>>>
>>> The following trivial, innocent looking code snippet does it in
>>> 3.8 and 3.9:
>>>
>>> | x y |
>>>   x := y := 0.
>>> {'a'. 'b'. 'c'} do: [:c|
>>>      (c string halt; endsWith: 'd')
>>>          ifTrue: [x:= 1 + x]
>>>          ifFalse: [y:= 1 + y]]
>>>
>>> Strange, why should Decompiler be involved in a halt situation,
>>> and then, why should it refuse to decompile code?
>>>
>>> /Klaus
>>>
>>>
>>>
>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Compiler+Decompiler together have a serious 'bad case' bug

Marcus Denker
In reply to this post by Klaus D. Witzel

On 23.07.2006, at 23:06, Klaus D. Witzel wrote:

> On Sun, 23 Jul 2006 16:52:01 +0200, Marcus Denker  
> <[hidden email]> wrote:
>> On 23.07.2006, at 16:31, Bert Freudenberg wrote:
>>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>>
>>>> Strange, why should Decompiler be involved in a halt situation
>>>
>>> I guess because there is no method source if you evaluate the code
>>> in a workspace.
>
> Good guess but I found the error in a regular .changes file source  
> coded method.
>
>> Printing of blocks for the stack-trace shown in the pre-debug window
>> nees the
>> decompiler...
>
> Strange, all source code is available.
Yes... the block-printing uses the decompiler right now, though...  
but thinking
about it, it should be possible to use the bc->text mapping (of the  
encoder)
to do the printing without decompiling... so printOn: would do
        1) compile the method that the block is in to get the MethodNode.
        2) get startPC / endPC of the blocks bytecode
        3) the MethodNode then has the bc-to-text mapping (MethodNode  
encoder, I think)
              that should return the start / end in the text of the  
method when giving it the bytecode interval
        4) print that text in printOn:

Anyone care to try to implement that?

      Marcus


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Compiler+Decompiler together have a serious 'bad case' bug

Bert Freudenberg-3
Am 24.07.2006 um 09:36 schrieb Marcus Denker:

> On 23.07.2006, at 23:06, Klaus D. Witzel wrote:
>
>> On Sun, 23 Jul 2006 16:52:01 +0200, Marcus Denker  
>> <[hidden email]> wrote:
>>> On 23.07.2006, at 16:31, Bert Freudenberg wrote:
>>>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>>>
>>>>> Strange, why should Decompiler be involved in a halt situation
>>>>
>>>> I guess because there is no method source if you evaluate the code
>>>> in a workspace.
>>
>> Good guess but I found the error in a regular .changes file source  
>> coded method.
>>
>>> Printing of blocks for the stack-trace shown in the pre-debug window
>>> nees the
>>> decompiler...
>>
>> Strange, all source code is available.
>
> Yes... the block-printing uses the decompiler right now, though...  
> but thinking
> about it, it should be possible to use the bc->text mapping (of the  
> encoder)
> to do the printing without decompiling... so printOn: would do
> 1) compile the method that the block is in to get the MethodNode.
> 2) get startPC / endPC of the blocks bytecode
> 3) the MethodNode then has the bc-to-text mapping (MethodNode  
> encoder, I think)
>              that should return the start / end in the text of the  
> method when giving it the bytecode interval
> 4) print that text in printOn:
>
> Anyone care to try to implement that?

If someone is implementing this, take care to use only the method  
referenced by the block, because the actual method might have changed  
since the block was created.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: [FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

Bert Freudenberg-3
In reply to this post by Klaus D. Witzel
Decompiler recompileAllTest

- Bert -

Am 23.07.2006 um 23:16 schrieb Klaus D. Witzel:

> It works, your and my example no longer fail.
>
> Is there a routine to check the modified Decompiler against all  
> source coded methods?
>
> /Klaus
>
> On Sun, 23 Jul 2006 16:23:31 +0200, Bert Freudenberg wrote:
>
>> Simpler test case - in a Browser, add this method:
>>
>> test
>> (self foo; bar)
>> ifTrue: [1]
>> ifFalse: [2]
>>
>> Then switch to "decompile" instead of "source".
>>
>> If the receiver of an ifTrue:ifFalse: is a cascade, the decompiler
>> mistakes it for a case statement. I attached a fix for that, could
>> someone please verify?
>>
>> - Bert -
>>
>>
>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>
>>> Sorry, hyperlink is
>>>
>>> - http://bugs.impara.de/view.php?id=4313
>>>
>>> /Klaus
>>>
>>> On Sat, 22 Jul 2006 23:37:07 +0200, Klaus D. Witzel
>>> <[hidden email]> wrote:
>>>
>>>> http://bugs.impara.de/view.php?id=2921
>>>>
>>>> You can provoke the emergency console by having Decompiler fail
>>>> with self error:'bad case' in #send:super:numargs.
>>>>
>>>> The following trivial, innocent looking code snippet does it in
>>>> 3.8 and 3.9:
>>>>
>>>> | x y |
>>>>   x := y := 0.
>>>> {'a'. 'b'. 'c'} do: [:c|
>>>>      (c string halt; endsWith: 'd')
>>>>          ifTrue: [x:= 1 + x]
>>>>          ifFalse: [y:= 1 + y]]
>>>>
>>>> Strange, why should Decompiler be involved in a halt situation,
>>>> and then, why should it refuse to decompile code?
>>>>
>>>> /Klaus
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: [FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

Klaus D. Witzel
Died (in 3.9b-7048) with the attached  
(ByteString(Object)>>doesNotUnderstand: #between:and:), with temps

aStream: a LimitedWriteStream 'isRoot: t1 '
kwd: 'isRoot:'
arg: {t1}
temp: nil
each: <primitive: 'primitiveIsRoot'>

Does it make sense to check other builds / releases, is recompileAllTest  
up-to-date?

/Klaus

On Tue, 25 Jul 2006 10:32:47 +0200, Bert Freudenberg wrote:

> Decompiler recompileAllTest
>
> - Bert -
>
> Am 23.07.2006 um 23:16 schrieb Klaus D. Witzel:
>
>> It works, your and my example no longer fail.
>>
>> Is there a routine to check the modified Decompiler against all source  
>> coded methods?
>>
>> /Klaus
>>
>> On Sun, 23 Jul 2006 16:23:31 +0200, Bert Freudenberg wrote:
>>
>>> Simpler test case - in a Browser, add this method:
>>>
>>> test
>>> (self foo; bar)
>>> ifTrue: [1]
>>> ifFalse: [2]
>>>
>>> Then switch to "decompile" instead of "source".
>>>
>>> If the receiver of an ifTrue:ifFalse: is a cascade, the decompiler
>>> mistakes it for a case statement. I attached a fix for that, could
>>> someone please verify?
>>>
>>> - Bert -
>>>
>>>
>>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>>
>>>> Sorry, hyperlink is
>>>>
>>>> - http://bugs.impara.de/view.php?id=4313
>>>>
>>>> /Klaus
>>>>
>>>> On Sat, 22 Jul 2006 23:37:07 +0200, Klaus D. Witzel
>>>> <[hidden email]> wrote:
>>>>
>>>>> http://bugs.impara.de/view.php?id=2921
>>>>>
>>>>> You can provoke the emergency console by having Decompiler fail
>>>>> with self error:'bad case' in #send:super:numargs.
>>>>>
>>>>> The following trivial, innocent looking code snippet does it in
>>>>> 3.8 and 3.9:
>>>>>
>>>>> | x y |
>>>>>   x := y := 0.
>>>>> {'a'. 'b'. 'c'} do: [:c|
>>>>>      (c string halt; endsWith: 'd')
>>>>>          ifTrue: [x:= 1 + x]
>>>>>          ifFalse: [y:= 1 + y]]
>>>>>
>>>>> Strange, why should Decompiler be involved in a halt situation,
>>>>> and then, why should it refuse to decompile code?
>>>>>
>>>>> /Klaus
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>



SqueakDebug.log (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

Marcus Denker

On 25.07.2006, at 11:29, Klaus D. Witzel wrote:

> Died (in 3.9b-7048) with the attached (ByteString(Object)
> >>doesNotUnderstand: #between:and:), with temps
>
> aStream: a LimitedWriteStream 'isRoot: t1 '
> kwd: 'isRoot:'
> arg: {t1}
> temp: nil
> each: <primitive: 'primitiveIsRoot'>
>
> Does it make sense to check other builds / releases, is  
> recompileAllTest up-to-date?
>
No... we don't have an automated testserver, thus test are almost  
never run. And tests
outside of SUnit are *never* run, of course....

In 3.8, there is a Smalltalk>>#testDecompiler, which was made a  
TestCase in 3.9a...
but it was kind of in a broken state, so I removed it to come back  
later to it...

FileOut attached.





       Marcus


DecompilerTests.st (21K) Download Attachment
smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

Klaus D. Witzel
On Tue, 25 Jul 2006 13:24:05 +0200, Marcus Denker wrote:
> On 25.07.2006, at 11:29, Klaus D. Witzel wrote:
> ...
>> Does it make sense to check other builds / releases, is
>> recompileAllTest up-to-date?
>>
>
> No... we don't have an automated testserver, thus test are almost
> never run. And tests
> outside of SUnit are *never* run, of course....

"automated testserver" is mentioned every now and then, is there something  
more tangible (whishlist, requirements)?

> In 3.8, there is a Smalltalk>>#testDecompiler, which was made a
> TestCase in 3.9a...
> but it was kind of in a broken state, so I removed it to come back
> later to it...
>
> FileOut attached.

Thank you. When running "self debug: #testDecompiler" it raises  
ResumableTestFailure because of the variable order of the temporaries,  
especially of those [only those?] thrown in by macros (example:  
Object>>#copyFrom:). Unbelievable that there'd been a change in macro  
generation which is not in sync with Decompiler (or vice versa). So what's  
up with macros?

/Klaus


Reply | Threaded
Open this post in threaded view
|

Re: [FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

stéphane ducasse-2
We hope to have somebody working full time two months on that  
starting in october. But this is not completely sure.

Stef

On 25 juil. 06, at 15:48, Klaus D. Witzel wrote:

> On Tue, 25 Jul 2006 13:24:05 +0200, Marcus Denker wrote:
>> On 25.07.2006, at 11:29, Klaus D. Witzel wrote:
>> ...
>>> Does it make sense to check other builds / releases, is
>>> recompileAllTest up-to-date?
>>>
>>
>> No... we don't have an automated testserver, thus test are almost
>> never run. And tests
>> outside of SUnit are *never* run, of course....
>
> "automated testserver" is mentioned every now and then, is there  
> something more tangible (whishlist, requirements)?
>
>> In 3.8, there is a Smalltalk>>#testDecompiler, which was made a
>> TestCase in 3.9a...
>> but it was kind of in a broken state, so I removed it to come back
>> later to it...
>>
>> FileOut attached.
>
> Thank you. When running "self debug: #testDecompiler" it raises  
> ResumableTestFailure because of the variable order of the  
> temporaries, especially of those [only those?] thrown in by macros  
> (example: Object>>#copyFrom:). Unbelievable that there'd been a  
> change in macro generation which is not in sync with Decompiler (or  
> vice versa). So what's up with macros?
>
> /Klaus
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [FIX] Re: Compiler+Decompiler together have a serious 'bad case' bug

Klaus D. Witzel
Thank you for your continued pushs and contributions, Stef.

As discussed with Marcus at the Squeak Stammtisch in Bern, I'll have a  
look at the Compiler+macros+Decompiler discrepancy. Will post whatever I  
find (hopefully a bug fix, who knows :)

BTW: have you seen

- http://bugs.impara.de/view.php?id=4322

Character>>#storeOn: will most likely not only break Decompiler, but all  
methods and procedures which aren't aware that objects like Character  
space are suddenly stored as a *message send*. Try

Object readFrom: #(3 $  4) storeString readStream

to see the mess in action.

/Klaus

On Wed, 26 Jul 2006 11:53:04 +0200, stéphane ducasse wrote:

> We hope to have somebody working full time two months on that starting  
> in october. But this is not completely sure.
>
> Stef