help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Bug with long recursion


From: Gwenael Casaccio
Subject: [Help-smalltalk] Bug with long recursion
Date: Tue, 26 Jul 2011 00:58:57 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11

Hi,

I've investigate a bit the long recursion bug, to debug I've choose a simple recursive code:

ObjectMemory growTo: 100 * 1024 * 1024. " This is not needed "
Object compile: 'foo: i [ i > 1 ifTrue: [ self foo: i - 1 ] ifFalse: [ #ici printNl ] ]'.
Object new foo: 1000000

If you run it it crashes, first you need to apply the mark patch. But
it still crash fortunately it says the OOP was free when trying to copy
it, but what was strange it was called in _gst_copy_registered_oops. So
it seems that a registered OOP or more (in fact more :s) is freed.

#0 0x00007ffff6ea8d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff6eacab6 in abort () at abort.c:92
#2 0x00007ffff7aea9ed in _gst_copy_an_oop (oop=0x2b5be31a6030) at oop.c:2099
#3  0x00007ffff7b27642 in _gst_copy_registered_oops () at callin.c:1124
#4  0x00007ffff7aea1c6 in copy_oops () at oop.c:1800
#5  0x00007ffff7ae9325 in _gst_scavenge () at oop.c:1265
...

To know where it happens I've putted a simple function called in _gst_sweep_oop that aborts when the oop is registered :

void
_gst_check_reg (OOP oop)
{
  rb_node_t *node;
  rb_traverse_t t;

/* Walk the OOP registry, yes I know this is not complete I should scan range of OOP... */
  for (node = rb_first(&(oop_registry_root->rb), &t);
       node; node = rb_next(&t))
    {
      oop_registry *k = (oop_registry *) node;
      if (k->oop == oop)
        {
        fprintf (stderr, "%O\n", oop); abort ();
        }
    }
}

And the problem occurs in function: reset_incremental_gc
when _gst_sweep is called (line 1451).

#2 0x00007ffff7b275f6 in _gst_check_reg (oop=0x2aac614ec890) at callin.c:1108
#3  0x00007ffff7ae9943 in _gst_sweep_oop (oop=0x2aac614ec890) at oop.c:1480
#4 0x00007ffff7ae9827 in reset_incremental_gc (firstOOP=0x2aac614e0030) at oop.c:1451
#5  0x00007ffff7ae8c69 in _gst_global_gc (next_allocation=0) at oop.c:1150
#6  0x00007ffff7ae9246 in _gst_scavenge () at oop.c:1235
...

But more intersting I've desactivated the incremental GC and the test works. I don't have a solution but hope that little investigation can help us to remove that "annoying" bug :-)

Cheers,
Gwen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]