[racket-dev] internal error during gc

Racket sometimes fails on openbsd/i386. The person who is in charge of 
the openbsd i386 packages has seen similar problems since the first day.

My usual tricks to build racket is increase the datasize (-d), the 
number of open files (-n) and the stack size (-s). I only use one job in 
raco.

In contrast to the i386 experience, racket works like a charm on 
openbsd/amd64.

Sincerely, I don't know if the bug is in racket or in openbsd.


On 12/29/2014 02:41 PM, Philippe Meunier wrote:
> Juan Francisco Cantero Hurtado wrote:
>> Works fine on my machine.
>
> I've re-built the whole thing several times over the past few days and
> it does not fail every time.  It has failed once out of the last three
> builds I did.
>
>> Try with "ulimit -d 1000000".
>
> My limit was already set at 1048576 :-) The racket process never
> reaches that size anyway.  Here are two graphs showing the size of the
> process over time, for two different successful builds:
> http://www.ccs.neu.edu/home/meunier/chart1.pdf
> http://www.ccs.neu.edu/home/meunier/chart2.pdf
> There's one data point every second.  The top and right edges of the
> graphs are the 1048576 KB limit.  The maximum size reached (in the
> second build) was 900116 KB.
>
> Interestingly, even tough these two builds succeeded and finished
> normally, I noticed that they both gave this error message:
>
> raco setup: rendering: <pkgs>/images-doc/images/scribblings/images.scrbl
> unmap failed: 814000, 278528, 22
> raco setup: rendering: <pkgs>/racket-doc/scribblings/inside/inside.scrbl
>
> In both builds the racket process was about 630 MB in size at the time
> this error message showed up.  The place where this error message
> showed up is the exact same place in the build where racket failed in
> my original email...
>
> Now here is a graph for a build that failed:
> http://www.ccs.neu.edu/home/meunier/chart3.pdf
> It failed again while processing images.scrbl, but during the
> "running" part of the build this time, not the "rendering" part:
>
> raco setup: running: <pkgs>/images-doc/images/scribblings/images.scrbl
> Seg fault (internal error during gc) at 0xd98004
> *** Signal SIGABRT in . (Makefile:62 'plain-in-place')
> *** Error 1 in /home/meunier/lang/racket.new (Makefile:44 'in-place')
>
> The "running: <pkgs>/.../images.scrbl" is always the point in the build
> where the racket process reaches its maximum size (883864 KB in this case),
> but the process was already back down to about 584 MB when the "internal
> error during gc" message showed up.
>
> Here is the backtrace from gdb on the core file:
>
> (gdb) bt
> #0  0x04a78b01 in kill () at <stdin>:2
> #1  0x04ae37f6 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39
> #2  0x04ae3740 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
> #3  0x16e9fc3c in fault_handler () from /home/meunier/lang/racket.new/racket/bin/racket
> #4  <signal handler called>
> #5  memcpy () at /usr/src/lib/libc/arch/i386/string/bcopy.S:66
> #6  0x16ea64b9 in GC_mark2 () from /home/meunier/lang/racket.new/racket/bin/racket
> #7  0x16e7de1f in scheme_register_traversers () from /home/meunier/lang/racket.new/racket/bin/racket
> #8  0x16ea6b54 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket
> #9  0x16ea6c5d in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket
> #10 0x16ea37a6 in GC_register_new_thread () from /home/meunier/lang/racket.new/racket/bin/racket
> #11 0x16ea5df4 in GC_dump () from /home/meunier/lang/racket.new/racket/bin/racket
> #12 0x16ea83ca in GC_malloc_atomic () from /home/meunier/lang/racket.new/racket/bin/racket
> #13 0x16ce7649 in scheme_generate_alloc_retry () from /home/meunier/lang/racket.new/racket/bin/racket
> #14 0x00236c9b in ?? ()
> #15 0x00000000 in ?? ()