Re: [racket-dev] internal error during gc
Juan Francisco Cantero Hurtado wrote: Sincerely, I don't know if the bug is in racket or in openbsd. Okay... Well, is anyone interested in trying to locate the cause of the problem? I can recompile the GC with debugging options turned on, etc., if more information is needed, but I don't know how the GC's code actually works and I don't have the time to dive into that... Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
I think the root of the problem is that `raco setup` gets anywhere close to the 1 GB limit. Also, since the images.scrbl document involves images, the problem may be related to using foreign libraries when close to the memory limit (where the foreign library can't force a Racket GC to recover from an allocation failure). Rendering images.scrbl by itself peaks somewhere between 600 MB and 700 MB in a 64-bit build, so I wouldn't expect it to be anywhere close to 1GB in 32-bit mode. Building within `raco setup` adds some extra overhead, and there may be a leak or finalizer interaction that makes `raco setup` carry along too much memory by the time it gets to images.scrbl. Of course, 700 MB is a lot of memory to build a 100-page manual. It takes only 700 MB instead of many GB because I periodically hunt down inefficiencies and leaks in an attempt to keep `raco setup` under control. It's past time for another hunt. At Tue, 30 Dec 2014 08:00:12 -0500, Philippe Meunier wrote: Juan Francisco Cantero Hurtado wrote: Sincerely, I don't know if the bug is in racket or in openbsd. Okay... Well, is anyone interested in trying to locate the cause of the problem? I can recompile the GC with debugging options turned on, etc., if more information is needed, but I don't know how the GC's code actually works and I don't have the time to dive into that... Philippe _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
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 100. 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 0x in ?? () Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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 100. 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 0x in ?? () _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Juan Francisco Cantero Hurtado wrote: Hi, OpenBSD -current or -stable? amd64 or i386? Stable i386. Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
On 12/20/2014 04:17 PM, Philippe Meunier wrote: Juan Francisco Cantero Hurtado wrote: Hi, OpenBSD -current or -stable? amd64 or i386? Stable i386. Works fine on my machine. Try with ulimit -d 100. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Hi, OpenBSD -current or -stable? amd64 or i386? On 12/17/2014 01:56 PM, Philippe Meunier wrote: Hello, I just tried building racket from scratch on OpenBSD 5.6 after cloning the github repository, and raco setup failed: [...] raco setup: rendering: pkgs/html-doc/html/html.scrbl raco setup: rendering: pkgs/images-doc/images/scribblings/images.scrbl unmap failed: d94000, 278528, 22 unmap failed: d94000, 278528, 22 Seg fault (internal error during gc) at 0xd94004 *** Signal SIGABRT in . (Makefile:62 'plain-in-place') *** Error 1 in /home/meunier/lang/racket.new (Makefile:44 'in-place') Running gdb on the core file gives: (gdb) bt #0 0x04c5bb01 in kill () at stdin:2 #1 0x04cc67f6 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39 #2 0x04cc6740 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 #3 0x17a72afc 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 0x17a79379 in GC_mark2 () from /home/meunier/lang/racket.new/racket/bin/racket #7 0x17a49c5e in scheme_init_thread () from /home/meunier/lang/racket.new/racket/bin/racket #8 0x17a79a14 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #9 0x17a79b1d in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #10 0x17a7 in GC_register_new_thread () from /home/meunier/lang/racket.new/racket/bin/racket #11 0x17a78cb4 in GC_dump () from /home/meunier/lang/racket.new/racket/bin/racket #12 0x17a79cca in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #13 0x17a79df2 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #14 0x17a7b810 in GC_malloc_one_tagged () from /home/meunier/lang/racket.new/racket/bin/racket #15 0x1784acc8 in scheme_malloc_fail_ok () from /home/meunier/lang/racket.new/racket/bin/racket #16 0x17953875 in scheme_alloc_flvector () from /home/meunier/lang/racket.new/racket/bin/racket #17 0x179544ee in scheme_integer_length () from /home/meunier/lang/racket.new/racket/bin/racket #18 0x09800fe7 in ?? () #19 0x9794ed58 in ?? () #20 0x9794ed58 in ?? () #21 0x7dff6308 in ?? () #22 0xbc34be90 in ?? () #23 0x9794ed84 in ?? () #24 0x0373e1b4 in ?? () #25 0x9794ed84 in ?? () #26 0xbc34be68 in ?? () #27 0x000d in ?? () #28 0x9794ee14 in ?? () #29 0xb81537a8 in ?? () #30 0x9794ed74 in ?? () #31 0xcfbdf450 in ?? () #32 0x0d46dc40 in ?? () #33 0x0cdcefa8 in ?? () #34 0x9fbfa530 in ?? () #35 0x0004 in ?? () #36 0x050049cf in ?? () #37 0xa0b12d78 in ?? () #38 0x9794edbc in ?? () #39 0x11073456 in ?? () #40 0x4074ce41 in ?? () #41 0x in ?? () Philippe _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
