Steel Bank Common Lisp

Milan Zamazal <pdm@...> writes:

> I always get crashes or freezes with the following trivial CLX program
> and all recent versions of SBCL, including 0.8.18, on my Debian x86
> system, Linux 2.6, CLX 0.6.  It happens even when both CLX and
> clock.lisp are compiled with (optimize (safety 3)).
>
> It looks like a SBCL bug to me.
>
> In case of crash, the crash is reported as follows:
>
>   Argh! gc_find_free_space failed (first_page), nbytes=16.
>      Gen Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs Mem-age
>      0: 129350     0     0     0     0 529397048 420552  2000000    0   0  0.0000
>      1:  1267   399    42    14   264  6942168 111144  8757120 1039   1  3.9396
>      2:     0     0     0     0     0        0     0  2000000    0   0  0.0000
>      3:     0     0     0     0     0        0     0  2000000    0   0  0.0000
>      4:     0     0     0     0     0        0     0  2000000    0   0  0.0000
>      5:     0     0     0     0     0        0     0  2000000    0   0  0.0000
>      6:     0     0     0     0     0        0     0        0    0   0  0.0000
>      Total bytes allocated=536339216
>   fatal error encountered in SBCL pid 15650
>   The system is too badly corrupted or confused to continue at the Lisp
>   level. If the system had been compiled with the SB-LDB feature, we'd drop
>   into the LDB low-level debugger now. But there's no LDB in this build, so
>   we can't really do anything but just exit, sorry.

This, to me, seems to suggest that something is inhibiting garbage
collection.  You have 500Mb of allocated stuff in the lowest
generation.  Tracking that down would be worthwhile -- to eliminate
conservatism as the problem, try running your program on a non-x86,
where the GC is a precise implementation Cheney's algorithm,
uncontaminated by ambiguous roots.  If that likewise crashes with a
heap exhaustion, then look through your code and its callees for
things which would inhibit garbage collection -- without-gcing is the
obvious operator, but there may be others.

> In case of freeze, gdb indicates the freeze happens at the following
> place:
>
>   0x0805864e in futex_wait (lock_word=0x986c514, oldval=-1213677184)
>       at linux-os.c:64
>   64      _syscall4(int,sys_futex,
>   (gdb) where
>   #0  0x0805864e in futex_wait (lock_word=0x986c514, oldval=-1213677184)
>       at linux-os.c:64

This could so easily be a bug in the Linux kernel; I don't know enough
about threads to help you here.

Cheers,

Christophe

>>>>> "CR" == Christophe Rhodes <csr21@...> writes:

    CR> This, to me, seems to suggest that something is inhibiting
    CR> garbage collection.

Thanks, Christophe, for pointing me in the right direction.  Apparently
the garbage collection is enabled, but still doesn't run or doesn't
collect the data.  When I explicitly invoke garbage collection in my
code with SB-EXT:GC, the program no longer crashes.  When I replaced the
SB-EXT:GC call with a ROOM call, the program crashed again soon and the
last reported room information was:

  Dynamic space usage is:   528,990,808 bytes.
  Read-only space usage is: 39,395,304 bytes.
  Static space usage is:    15,537,728 bytes.
  Control stack usage is:   -4,294,964,400 bytes.
  Binding stack usage is:   4,294,967,624 bytes.
  Control and binding stack usage is for the current thread only.
  Garbage collection is currently enabled.

  Breakdown for dynamic space:
    233,960,384 bytes for   773,768 simple-character-string objects.
    82,671,584 bytes for 1,930,105 instance objects.
    67,804,736 bytes for 1,152,922 simple-array-unsigned-byte-32 objects.
    55,920,704 bytes for   390,853 simple-vector objects.
    34,040,136 bytes for 4,255,017 cons objects.
    55,170,200 bytes for 5,622,449 other objects.
    529,567,744 bytes for 14,125,114 dynamic objects (space total.)

And the crash report:

  Argh! gc_find_free_space failed (first_page), nbytes=16.
     Gen Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs Mem-age
     0: 129128     0     0     0     0 528468824 439464  2000000    0   0  0.0000
     1:   247    41     0     0   129  1112384 67264  2000000  115   0  5.7746
     2:  1249   332    43    32    60  6723056 59920  2000000 1183   0  0.0000
     3:     0     0     0     0     0        0     0  2000000    0   0  0.0000
     4:     0     0     0     0     0        0     0  2000000    0   0  0.0000
     5:     0     0     0     0     0        0     0  2000000    0   0  0.0000
     6:     0     0     0     0     0        0     0        0    0   0  0.0000
     Total bytes allocated=536304264

Is there any difference between the (SB-EXT:GC) call and automatic
garbage collection?  According to the ROOM information garbage
collection is always enabled at that place, so I wonder about the very
different behavior after putting the (SB-EXT:GC) call into the code.

FWIW, the strings are partially created with FORMAT calls in my code and
given to XLIB:DRAW-GLYPHS.  I don't know about the instance and array
objects, they must come from CLX, I don't use CLOS nor arrays in my
code.

    CR> try running your program on a non-x86, where the GC is a precise
    CR> implementation Cheney's algorithm, uncontaminated by ambiguous
    CR> roots.

Unfortunately, I don't have access to any non-x86 where I could run an X
program, so I couldn't try this.

Regards,

Milan Zamazal

-- 
Here is my advice, don't try to program the bleeding edge for the
general populace unless you really, really, really like migraines.
						   Neal H. Walfield