Frank, could you retry to launch the script with Compiler copy evaluate:
'...' instead of Compiler evaluate: ?
I checked that
Compiler copy methodDictionary ~~ Compiler methodDictionary
so it might just work...


2013/9/25 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>

> Nah, I'm cheating.
> I just opened a recent artifact from CI server one or two days ago.
> It has the same kind of debugger opened
> http://build.squeak.org/job/SqueakTrunk/537/
>
>
> 2013/9/25 Bob Arning <arning315 at comcast.net>
>
>>  Are you able to tell what's in the script he's running simply from the
>> stack trace? Or some other way?
>>
>> Cheers,
>> Bob
>>
>>  On 9/25/13 9:12 AM, Nicolas Cellier wrote:
>>
>>   The problem is that the script you evaluate will update the Compiler...
>> New updates will remove unused variables before the script is finished...
>> I tried to solve the problem by introducing an intermediate step:
>>  - 1) publish the modified methods in an update.mcm (I reintroduced the
>> missing vars)
>>  - 2) only then remove the inst. var.
>>  (See the recent serie of Compiler versions 270->274
>>
>>  This did not solve anything because there are always cases when you
>> launch the script from an older image (typically from Squeak 4.4, 4.3 or
>> even older)
>>  The same old Compiler instance is used during all the process and it
>> must be unmodified during the process, otherwise, undefined behavior (SEGV
>> included)...
>>
>>  I see one way to workaround this:
>>  1) clone the Compiler class
>>  2) instantiate the clone
>>  3) let the clone evaluate
>>
>>  In fact, to be safer we should clone the whole hierarchy, but you could
>> 1st try simply with Compiler...
>>
>>
>> 2013/9/25 Bob Arning <arning315 at comcast.net>
>>
>>>  Just type
>>>
>>> PositionableStream>>#fileInAnnouncing:
>>>
>>> and explore it. Look for the literal pointing to the compiler (literal8
>>> here). Toggle that open and toggle open the value. Look at the
>>> instanceVariables - does it still have sourceStream?
>>>
>>> As to the explorer, did you open one? Is it still open? (The
>>> PointerFinder says it is) Could it have been open when the image was last
>>> saved?
>>>
>>>
>>> Also, you could do
>>>
>>> Behavior allSubInstances select: [ :e | (e asString findString:
>>> 'Compiler') > 0]
>>>
>>> Do you get: an OrderedCollection(ClosureCompilerTest CompilerTest
>>> CompilerExceptionsTest CompilerNotifyingTest
>>> CompilerSyntaxErrorNotifyingTest Compiler ClosureCompilerTest class
>>> CompilerTest class CompilerExceptionsTest class CompilerNotifyingTest class
>>> CompilerSyntaxErrorNotifyingTest class Compiler class)
>>>
>>>
>>> Cheers,
>>> Bob
>>>
>>>   On 9/25/13 7:31 AM, Frank Shearar wrote:
>>>
>>> I don't know how I would do that. The bytecode just says pushLit: Compiler.
>>>
>>> But if I say Compiler allInstances collect: [:c | c instVarNamed:
>>> 'cue'] I see {nil . a CompilationCue . a CompilationCue}. That first
>>> one's a problem! Further, my image has an ObjectExplorer (!) hanging
>>> onto that Compiler, coming from I don't know where.
>>>
>>> frank
>>>
>>> On 25 September 2013 11:53, Bob Arning <arning315 at comcast.net> <arning315 at comcast.net> wrote:
>>>
>>>  If you inspect
>>>
>>> PositionableStream>>#fileInAnnouncing:
>>>
>>> and look at the literal for Compiler, does it look to be pointing to the new
>>> or old Compiler?
>>>
>>> Cheers,
>>> Bob
>>>
>>> On 9/25/13 6:12 AM, Frank Shearar wrote:
>>>
>>> I'm running with Compiler-nice.274.
>>>
>>> What's weirder is in that top stack frame (Compiler >>
>>> #evaluate:in:to:notifying:ifFailed:logged: the following all show up
>>> as red, because they're references to instvars that don't exist:
>>> class, sourceStream, context, requestor.
>>>
>>> That's because the CompiledMethod that's running is not actually the
>>> right CompiledMethod! It's from some ancient pre-CompilationCue
>>> Compiler instance. Or at least so I suspect because that Compiler
>>> instance has a nil 'cue' instvar.
>>>
>>> If it helps, the PointerFinder says this of the offending context:
>>>
>>> globals: Environment
>>> declarations: IdentityDictionary
>>> #World -> PasteUpMorph
>>> submorphs: Array
>>> 1: SystemWindow
>>> model: ObjectExplorer
>>> currentSelection: ObjectExplorerWrapper
>>> item: CompiledMethod
>>>
>>> In contrast, PointerFinder on: (Compiler >>
>>> #evaluate:in:to:notifying:ifFail:logged:) says:
>>>
>>> CLASS: SmalltalkImage class
>>> superclass: Object class
>>> subclasses: Array
>>> 445: Compiler class
>>> methodDict: MethodDictionary
>>> array: Array
>>> 39: CompiledMethod.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131003/c0dde85f/attachment.htm