Decompiler problem (leading to infinite loop of opening debuggers)

Hi,

In Pharo1.2.x, I get an infinite recursion of a debugger windows opening when I load a metacello config that has a problem in it.
The relevant problem can be reconstructed (without the infinite loop :-) by evaluation the following:

 (MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) decompileWithTemps

I'm absolutely no compiler guy, so I'm totally unaware of what is happening.
But it's serious because I cannot debug the actual problem of the metacello config because of this.

It was tried with Pharo1.2.1 and Pharo1.2.2-12353 and latest Cog VM (27 April 2011).

I entered issue 4241 in the bug tracker for this.

Johan

I haven't figured out the exact decompiler bug yet, but just so you can
easily fix your problem:

just move the temp in the whileFalse: [ |newReqd| to the toplevel of the
method (if this is semantically equivalent; but it looks like).
Then it can actually decompile it ;)

cheers,
Toon

On 05/18/2011 12:16 PM, Johan Brichau wrote:
>   (MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) decompileWithTemps

On May 18, 2011, at 1:26 PM, Toon Verwaest wrote:

> I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem:
>

I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler.

We could backport the compiler fixes to 1.2...

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

On 05/18/2011 01:30 PM, Marcus Denker wrote:
> On May 18, 2011, at 1:26 PM, Toon Verwaest wrote:
>
>> I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem:
>>
> I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler.
>
> We could backport the compiler fixes to 1.2...
Oh ok, then I don't even look further. But that decompiler is a mess ...
moving to OPAL would be a great improvement I'd say ...

On May 18, 2011, at 1:32 PM, Toon Verwaest wrote:

> On 05/18/2011 01:30 PM, Marcus Denker wrote:
>> On May 18, 2011, at 1:26 PM, Toon Verwaest wrote:
>>
>>> I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem:
>>>
>> I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler.
>>
>> We could backport the compiler fixes to 1.2...
> Oh ok, then I don't even look further. But that decompiler is a mess ... moving to OPAL would be a great improvement I'd say ...
:-)


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

thanks guys!

I didn't test in 1.3 indeed.

btw, since moving to 1.2, after doing pullup or pushdown refactorings, I often get methods that badly reference instance variables. Their instvar index seems to be off in the sense that the name references another variable. I can fix the problem by recompiling the method but it's quite a pain. Unfortunately, I have been unsuccessful in creating a scenario that always works... I hope to do that asap.

2011/5/18 Toon Verwaest <[hidden email]>:
Yes this code is very hard to track by just reading code... So hard to
maintain too. Too many states in a single class.
And you often discover that the processing you were looking for in
fact was coded somewhere else (like in MessageNode).
The best way to understand the old Decompiler is to debugIt.

Nicolas