The clue here is the magic number

-2145977416 >new:
-2145977508 NSStringWriter>nextPutAll:
-2145977600 [] in NSBenchmarks>benchStringNextPutAllString
-2145977692 Integer>timesRepeat:
2030103240 [] in NSBenchmarks>benchStringNextPutAllString

in front of the stack trace which is the memory address for the  
stack. It's gone negative since you've gone over the 2GB boundary.
However most VMs out there are NOT safe to run with addresses > 2GB.  
They die, as you see.

There has been work lately by David T Lewis to address this issue but  
I don't think it has been compiled into any of the official VMs yet.

If this is unix try fiddling with the memory parm value to see if you  
can load the VM lower down in virtual memory.


On May 27, 2007, at 12:19 AM, Damien Cassou wrote:

> Hi Klaus,
>
> 2007/5/27, Klaus D. Witzel <klaus.witzel at cobss.com>:
>> on Sat, 26 May 2007 23:09:04 +0200, you wrote:
>> > while I was working with Nile (a new stream library) the VM  
>> crashed.
>> >
>> > You can reproduce it very easily. Download a fresh 3.9-7067,  
>> install
>> > Nile-All from monticello (http://www.squeaksource.com/Nile/).
>>
>> Perhaps a method still accesses an iVar which has gone away, can  
>> you do
>> something like
>>
>> Smalltalk allClassesAndTraits do:
>>   [:classOrTrait | ('Nile-*' match: classOrTrait category)
>>         ifTrue: [classOrTrait compileAll]]
>>   displayingProgress: 'Recompiling Nile classes and traits'.
>
> It didn't change anything for me. The VM crashed.
>
> -- 
> Damien Cassou
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===