From: <Gis...@bc...> - 2006-06-14 15:00:36
|
I'm writing/running a program that handles a large number of protein structures, each requiring a significant amount of memory. I don't want to read these structures into memory each time I need them, so I cache them in a hash table. Whenever the process pass just undre 800 MB (according to top), sbcl crash with the following error message. mmap: Cannot allocate memory fatal error encountered in SBCL pid 32008(tid 182901392576): remap_free_pages: page moved, 0x0001d2d1 ==> 0x00000000 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. Apparently it is running out of memory, but that don't make sense, since the machine is an x86-64 with 8GB of memory, and I'm using the 64-bit version of sbcl, that maps 8GB of memory (and top agree here), so effectively I should only be using about 10% of the available memory. To continue debuging I'm told (according to the error message) to use SB-LDB, but according to the sbcl-internals wiki (http://sbcl-internals.cliki.net/ldb), I should add :sb-ldb to the file customize-target-features.lisp, but I can't find this file in the sbcl source tree. Furthermore, when trying with GDB, it stops time after time with "segmentation fault", so gdb alone is not useful for debuging. While I think to remember it mentioned somewhere that the "segfaults" is a part of the normal operation of the garbage collector (or similar), it don't help either. Does anyone have a clue what is going on, and where I can go from here? |
From: Juho S. <js...@ik...> - 2006-06-14 16:35:24
|
Gisle S=E6lensminde <Gis...@bc...> writes: > mmap: Cannot allocate memory > fatal error encountered in SBCL pid 32008(tid 182901392576): > remap_free_pages: page moved, 0x0001d2d1 =3D=3D> 0x00000000 This has been discussed on sbcl-devel a couple of times this year, you should be able to find the discussions by searching for the error message in the mailing list archives. Alternatively CVS SBCL should give you an error message which explains exactly what is wrong, and what you can do on your system to fix it. --=20 Juho Snellman |
From: William H. N. <wil...@ai...> - 2006-06-14 19:13:46
|
On Wed, Jun 14, 2006 at 05:00:01PM +0200, Gisle S?lensminde wrote: > To continue debuging I'm told (according to the error message) to use > SB-LDB, but according to the sbcl-internals wiki > (http://sbcl-internals.cliki.net/ldb), I should add :sb-ldb to the file > customize-target-features.lisp, but I can't find this file in the sbcl > source tree. Hmm, yes. That file is not *supposed* to be in the source tree, because the point is that it's where you make changes that shouldn't be pulled into CVS and whatnot, but the old instructions didn't explain that, and now that you point it out, I can see how it would be surprising, and perhaps look more like out-of-date documentation than like a correct explanation of what you should do to do. I have now added some text (to http://sbcl-internals.cliki.net/ldb and to the comments in base-target-features.lisp-expr) to try to try to clarify that. Thanks for pointing it out. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: <Gis...@bc...> - 2006-06-14 21:52:46
|
Juho Snellman wrote: >Gisle Sælensminde <Gis...@bc...> writes: > > >>mmap: Cannot allocate memory >>fatal error encountered in SBCL pid 32008(tid 182901392576): >>remap_free_pages: page moved, 0x0001d2d1 ==> 0x00000000 >> >> > >This has been discussed on sbcl-devel a couple of times this year, you >should be able to find the discussions by searching for the error >message in the mailing list archives. > >Alternatively CVS SBCL should give you an error message which explains >exactly what is wrong, and what you can do on your system to fix it. > > > I did not find it on sbcl-devel (may not have searched properly), but I found something on the log for the #lisp IRC channel. Search for "mprotect" in the page at http://tunes.org/~nef/logs/lisp/06.05.30. It seems like that when too much (about 1GB) of memory is allocated, the maximal number of mprotected regions are exeeded, and sbcl crash. The maximal number of mprotected regions are 65536 by default, and this can safely be increased, allowing more memory to be allocated, by setting a greater value in /proc/sys/vm/max_map_count. I do not have administrator access to the computer in question. That mean I have to convince the sysadmin to change the value. Hopefully this will solve my problem. |
From: Nicolas N. <Nic...@iw...> - 2006-06-15 07:00:39
|
Gisle S=E6lensminde <Gis...@bc...> writes: > I did not find it on sbcl-devel (may not have searched properly), but I I think Juho is refering besides others to a thread called "SBCL on AMD64" starting at Mon, 13 Mar 2006 (I had similar problems). Yours, Nicolas. |