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