VM crash with image 3.9

Hi,

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/).

In a workspace, execute: "NSBenchmarks new benchStringNextPutAllString"

Then, you get:

sweep failed to find exact end of memory

-2145977416 >new:
-2145977508 NSStringWriter>nextPutAll:
-2145977600 [] in NSBenchmarks>benchStringNextPutAllString
-2145977692 Integer>timesRepeat:
2030103240 [] in NSBenchmarks>benchStringNextPutAllString
2030103424 [] in NSBenchmarks>benchWithSqueakStream:andNileStream:do:
-2145996892 BlockContext>bench
2030103644 [] in NSBenchmarks>benchSqueak:Nile:
2030103060 Integer>timesRepeat:
2030102968 NSBenchmarks>benchSqueak:Nile:
2030102876 NSBenchmarks>benchWithSqueakStream:andNileStream:do:
2030102784 NSBenchmarks>benchStringNextPutAllString
2030102692 UndefinedObject>?
2030100224 Compiler>evaluate:in:to:notifying:ifFail:logged:
2030099892 [] in ParagraphEditor>evaluateSelection
2030099792 BlockContext>on:do:
...

--
Damien Cassou

Hi Damien,

on Sat, 26 May 2007 23:09:04 +0200, you wrote:
> Hi,
>
> 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'.

> In a workspace, execute: "NSBenchmarks new benchStringNextPutAllString"

Did not crash after the above recompile, instead it prints
   185.1335988978503->167.2261709346418

/Klaus

Hi Klaus,

2007/5/27, Klaus D. Witzel <[hidden email]>:
It didn't change anything for me. The VM crashed.

--
Damien Cassou

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:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

2007/5/27, John M McIntosh <[hidden email]>:

If I understand correctly, my algorithm uses far too much memory and
this memory is never GCed.


> 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.

What is this value? How do I change it?

--
Damien Cassou

2007/5/27, Damien Cassou <[hidden email]>:
> If I understand correctly, my algorithm uses far too much memory and
> this memory is never GCed.

I've just found the problem. All benchs were always using the same
stream instead of creating a new one each time. This made the internal
collection very big.

--
Damien Cassou

On Sun, May 27, 2007 at 01:26:46AM -0700, John M McIntosh wrote:
> 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.

I don't know if my VM changes are actually doing any good for the >2GB
problem. I just sent a note to vm-dev to ask for feedback.

Dave

On 27-May-07, at 2:51 AM, Damien Cassou wrote:

> 2
>
> If I understand correctly, my algorithm uses far too much memory and
> this memory is never GCed.
>
Although in this particular case on this particular machine might be  
triggered by a very high usage of memory space it is not the cause of  
the underlying problem. If by chance you machine/OS/memory layout  
happened to allocate Squeak's object memory starting at 2gb - 2mb and  
you loaded even a small image you would be in danger; as soon as your  
objectmemory address space *crosses* 2gb it is a problem.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"I love deadlines. I love the whooshing noise they make as they go  
by." Douglas Adams, R.I.P.