On Fri, Dec 31, 2010 at 2:25 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi All,
>     thanks to everyone finding bug cases.  Please keep it up.  I'm anxious
> to find a reproducible case for a crash in (what I thought was fixed)

Hi Eliot, I was able to launch the Squeak4.2-10779-alpha.image with
the new VM, but when I tried to open a file list it crashed with the
following information in the console:

Case not found and no otherwise clause



Smalltalk stack dump:
0xbfb87c0c I Color>slightlyDarker 2026011364: a(n) Color
0xbfb87c30 I Color>atMostAsLuminentAs: 2025218908: a(n) Color
0xbfb87c64 I PluggableTreeMorph(SimpleHierarchicalListMorph)>lineColor
2024731300: a(n) PluggableTreeMorph
0xbfb87c88 I PluggableTreeMorph(SimpleHierarchicalListMorph)>drawLinesOn:
2024731300: a(n) PluggableTreeMorph
0xbfb87cac I PluggableTreeMorph(SimpleHierarchicalListMorph)>drawOn:
2024731300: a(n) PluggableTreeMorph
0xbfb87cc8 M FormCanvas>? 2025370248: a(n) FormCanvas
0xbfb87ce4 M FormCanvas>? 2025370248: a(n) FormCanvas

Segmentation fault


Most recent primitives
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primRenderScanline:with:
primFinishedProcessing
primGetTimes:
primGetCounts:
primGetBezierStats:
wait
at:put:
signal
@
@
basicNew
@
perform:with:
@
@
perform:with:
@
basicNew
basicNew
new:
@
basicNew
at:put:
@
basicNew
at:put:
@
@
basicNew
at:put:
@
@
basicNew
at:put:
copyBits
copyBits
copyBits
copyBits
@
@
basicNew
copyBits
copyBits
basicNew
basicNew
at:put:
digitCompare:
new:
at:put:
at:put:
at:put:
at:put:
@
perform:with:
@
@
perform:with:
@
basicNew
@
@
basicNew
@
perform:with:
@
@
perform:with:
@
basicNew
copyBits
@
@
basicNew
@
perform:with:
@
@
perform:with:
@
basicNew
basicNew
new:
@
basicNew
at:put:
@
basicNew
at:put:
@
@
basicNew
at:put:
@
@
basicNew
at:put:
copyBits
copyBits
copyBits
copyBits
@
@
basicNew
copyBits
copyBits
@
@
basicNew
@
@
basicNew
@
@
basicNew
@
perform:with:
@
@
perform:with:
@
basicNew
copyBits
*
*
*
*
*
*
perform:with:
*
/
perform:with:
/
perform:with:
*
perform:with:
/
basicNew
truncated
fractionPart
fractionPart
truncated
fractionPart
truncated
fractionPart
truncated
perform:with:
*
perform:with:
/

[1]+  Aborted                 (core dumped) squeak Squeak4.2-10779-alpha.image


On Fri, Dec 31, 2010 at 2:25 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi All,
>     thanks to everyone finding bug cases.  Please keep it up.  I'm anxious
> to find a reproducible case for a crash in (what I thought was fixed)
> bytecode to machine code pc mapping with the r2333 VMs which has a stack
> trace like the following:
> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
> 0   com.teleplace.Teleplace         0x000b8ca6 mapForbcpcperformUntilarg +
> 166 (cogit.c:10929)
> 1   com.teleplace.Teleplace         0x000b8f3c mcPCForstartBcpcin + 44
> (cogit.c:11480)
> I get it only intermittently (ironically when pushing out a new version of
> the VM sources) and would love to find a reproducible case.  So if anyone
> sees this I'd be indebted if you could spend some time trying to make it
> easily reproducible.
> TIA
> Eliot
> On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>>
>> Hi All,
>>      I've released a new version of Cog that has a substantially improved
>> code generator along the lines of Peter Deutsch's HPS (VisualWorks) and
>> various of Ian Piumarta's VMs.  These all use a simple tecnique to identify
>> constant references in bytecode and to support a register-based calling
>> convention.  While this does produce faster code it tends to accelerate
>> low-level code much more than high-level code as you can see by the
>> following benchmarks:
>> SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691
>> StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192
>> 192 - 691 / 6.91 -72%
>> SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127
>> sends/sec'
>> StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec;
>> 128157989 sends/sec'
>> 931756141 - 753495217 / 7534952.17 -24%
>> 128157989 - 64769127 / 647691.27 -98%
>> SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no
>> transcript
>> StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no
>> transcript)
>> 43406 - 47013 / 470.13 -7.67234594686576
>> The status of this code is essentially beta.  The test suite runs the same
>> on the new code generator as on the old, but I think there are still bugs
>> because I get the occasional transient error.  I am therefore very
>> interested in any reproducible errors you can find.
>> The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few
>> other important changes:
>> - a bug fix to bytecode<->native pc mappng that produced incorrect results
>> for methods containing blocks with ^-returns in them.  One symptom is
>> incorrect highlighting of the pc in the debugger, althoguh symptoms could be
>> much serious.
>> - jitting interpreted methods on backward branches.  Currently any
>> interpreted method that performs more than 20 backward branches will be
>> considered for JIT compilation and if it is suitable (default, <= 60
>> literals) will be compiled to native code.
>> - new callback support.  I need to commit some changes to the Alien
>> package to provide access to this but essentially the VM's callback support
>> is now able to be ported to architectures with register-based calling
>> conventions (ARM, PowerPC, SPARC etc).  I'll try and get the Alien code
>> released soon, and to back-port the changes to the standard VM before the
>> end of the holiday.
>> One thing that is still /not/ fixed is the lack of a SoundPlugin on win32.
>>  Apologies.  I'll try and get a fix for this before the end of the holidays
>> too, but time might be too tight.  There are other priorities such as
>> harmonising the standard and Cog VMs for the 4.2 release.
>> best
>> Eliot
>
>
>
>
>