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.)
Von: Squeak-dev <[hidden email]> im Auftrag von Fabio Niephaus <[hidden email]> Gesendet: Donnerstag, 12. September 2019 13:23:57 An: The general-purpose Squeak developers list Betreff: [squeak-dev] Context>>#tempNames can raise Syntax Error
While debugging a failing Seaside test on Squeak trunk (see ), I
learned that Context>>#tempNames can raise a syntax error. Here's a
`Context allInstances collect: [:e | e tempNames]`
Anyone willing to look into this? When I try to debug the "calling
process", my image freezes...