Hi,
just to share my observations: I tested your repro in a few different images and found out the following similarities:
* The syntax error is raised by the attempt to create a DebuggerMethodMap for certain contexts * I did not always manage to chase the pointers of the causing contexts * But for example, in most images on my disk, one of them is (((World instVarNamed: #worldState) instVarNamed: #stepList) instVarNamed: #sortBlock) * The context's method is not currently installed (#isInstalled) * Decompiling that method *with temps* fails because its trail returns an invalid source pointer (usually a few hundred chars too big) * Basically, the invalid state appears to be created in CompiledMethodTrailer >> #decodeSourcePointer
But I have no clue how this implementation works. Is it possible that is erroneous, or might the SourceFile be corrupted?
(Btw, the image freezes because DebuggerMethodMap class uses a Mutex while caching the new map.)
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Fabio Niephaus lists@fniephaus.com Gesendet: Donnerstag, 12. September 2019 13:23:57 An: The general-purpose Squeak developers list Betreff: [squeak-dev] Context>>#tempNames can raise Syntax Error
Hi all,
While debugging a failing Seaside test on Squeak trunk (see [1]), I learned that Context>>#tempNames can raise a syntax error. Here's a repro doIt:
`Context allInstances collect: [:e | e tempNames]`
Anyone willing to look into this? When I try to debug the "calling process", my image freezes...
Cheers, Fabio
[1] https://travis-ci.org/SeasideSt/Seaside/jobs/578335182#L2733