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 at lists.squeakfoundation.org> im Auftrag von Fabio Niephaus <lists at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191104/f0552045/attachment.html>