There's one difference between the two versions. Using 
Compiler-eem.300, the following methods are compiled with small frame 
instead of large frame:

BitBltDisplayScanner>>#displayLines:in:clippedBy:
GradientFillStyle>>#computePixelRampOfSize:
InterpolatedGradientFillStyle>>#computePixelRampOfSize:
NewParagraph>>#clickAt:for:controller:
PackageInfo>>#changeRecordsForMethod:do:
PaintBoxMorph>>#addBrushesOffImage:
PaintBoxMorph>>#addShapeButtonsOffImage:onImage:
PaintBoxMorph>>#addToolsOffImage:onImage:
Paragraph>>#clickAt:for:controller:
PianoRollScoreMorph>>#addNotes
PolygonMorph>>#lineSegmentsDo:
PostscriptCharacterScanner>>#displayLine:offset:leftInRun:
SmalltalkImage>>#appendChangesTo:
StrikeFontSet>>#characters:in:displayAt:clippedBy:rule:fillColor:kernDelta:on:
SuperSwikiServer>>#fastParseEntriesFrom:
TTFontReader>>#processGlyphDataTable:offsets:
TextStyle class>>#fontMenuForStyle:target:selector:highlight:
Unicode class>>#parseCompositionMappingFrom:

Levente

On Tue, 7 Jul 2015, David T. Lewis wrote:

> On Tue, Jul 07, 2015 at 05:20:52PM -0700, Eliot Miranda wrote:
>> Hi David,
>>
>> On Tue, Jul 7, 2015 at 4:33 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>>>
>>> The problem was introduced in Compiler-eem.300, which does this:
>>>
>>>     Use the size/emitPushNClosureTemps: api in block generation.
>>>
>>> There are two affected methods:
>>>
>>>     BlockNode>>sizeCodeForEvaluatedClosureValue:
>>>     BlockNode>>emitCodeForEvaluatedClosureValue:encoder:
>>>
>>> Reverting these two methods fixes the problem.
>>>
>>> I don't know the background on this change but my guess would be that
>>> it is something that works on a stack interpreter but not on a context
>>> interpreter, so maybe the methods need to be tweaked to account for the
>>> difference.
>>>
>>
>> It should make no difference to the code produced.  It adds a new way of
>> saying "push N nils" that allows the Sista bytecode set to use its
>> "pushNClosureNils" bytecode to push several nils in one bytecode.  But with
>> the standard encoder EncoderForV3PlusClosures exactly the same code as the
>> previous version should be produced.
>>
>> How do the changes in the compiler cause the crash?
>>
>
> I don't know.
>
> I'm doing brute-force debugging, just rolling the versions back until the
> problem goes away.
>
> All I can say with confidence is that those two methods changes, followed by
> a system recompile, result in an image that crashes a context interpreter VM.
> Reverting these two methods and recompiling brings the image back to a sane
> condition.
>
> It might turn out to be a trivial problem, but I am suggesting that we should
> temporarily revert and work it out after the 4.6 release.
>
> Dave
>
>
>