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 ?? ()
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
