Re: [Help-smalltalk] GC Crash/Bug due recursion?

[Gwenael Casaccio]

On 06/10/2011 04:27 PM, Paolo Bonzini wrote:
> On Fri, Jun 10, 2011 at 16:15, Holger Hans Peter Freyther
> <address@hidden>  wrote:
> > On 06/10/2011 04:11 PM, Paolo Bonzini wrote:
> >
> > > Looks like an infinite loop in Smalltalk... Do you have enough stack
> > > space to do a "call _gst_show_backtrace(stdout)" from gdb?
> >
> > Hi,
> >
> > yes, I just wonder if things should crash or if this can be prevented, it
> > seems to create an infinite loop in the GC which is weird... of course with
> > recursion in smalltalk the stack will be full too..
>
> Yes, I think the problem is that the C stack of the marker is
> exhausted before the whole Smalltalk stack is visited.
>
> Paolo
>
> _______________________________________________
> help-smalltalk mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,

I've made an iterative mark it works for long structure like :

Object subclass: Foo [
 | previous next|
 previous: anObject [
   previous := anObject
 ]
 next: anObject [
   next:= anObject
 ]
 next [
   ^ next
 ]
]

 | last |
last := Foo new.
1000000 timesRepeat: [ | f|
  f := Foo new.
  f previous: last.
  last next: f.
  last := last next. ]

This bench stresses well the it. mark patch and crashes the rec. mark.
But I guess there are still bugs with contexts (I should take a look),
there is a strange crash (DNU with #printNl lookup symbol is not found 
but it's present...). But that's a good start :-)

It's possible instead of the iterative version to use a mark with a 
pointer reversal but it's harder to debug, requires high time-cost:
visits each branch-node at least (n+1) times, each visit requires 
additional memory fetches, and  each visit cycles 4 values + 
reading/writing mark-flags.

Another solution is to use a stack guard (v8 does it) and checks 
overflow Knuth propose something similar

Gwen

mark.patch
Description: Text Data