#2661 SBCL dies with "Heap exhausted" trying to load lapack

None
wont-fix
nobody
5
2015-02-16
2013-11-16
No

Working w/ SBCL 1.0.55 + current Git sources (post-5.31). load(lapack) chugs along for a while, then dies with:

; compiling file "/usr/local/share/maxima/branch_5_31_base_120_g0cb3b12_dirty/share/lapack/lapack/dgesvd.lisp" (written 15 NOV 2013 06:40:57 PM):
; compiling (IN-PACKAGE :LAPACK)
; compiling (LET* (# #) ...)Heap exhausted during garbage collection: 4096 bytes available, 4104 requested.
 Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs Mem-age
   0: 80332     0     0     0 12980  6405     0     0     0 40253808 39147152 40293769    0   1  0.0000
   1: 26462 131070     0     0   187 32005     0     0    27 66397440 65460992 26843545   83   0  0.5980
   2: 121922 121860     0     0 16576 28639   334   112   137 133104632 53922824 82661609 15780   1  0.4194
   3: 54155 54152 37820     0 13230  6149   584    97   140 74733632 7432128  2000000 12871   0  0.2994
   4:     0     0     0     0     0     0     0     0     0        0     0  2000000    0   0  0.0000
   5:     0     0     0     0     0     0     0     0     0        0     0  2000000    0   0  0.0000
   6:     0     0     0     0 11459  2224     0     0     0 56045568     0  2000000 11328   0  0.0000
   Total bytes allocated    = 370535080
   Dynamic-space-size bytes = 536870912
GC control variables:
   *GC-INHIBIT* = true
   *GC-PENDING* = in progress
   *STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 23427(tid 3084601024):
Heap exhausted, game over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> 

Discussion

  • Raymond Toy

    Raymond Toy - 2013-11-16

    I think this is a known issue. It has been reported on quicklisp too. SBCL uses a large amount of memory to compile the lapack library. The default heap size is too small. CMUCL with it's default heap of 512MB can compile it for some reason. I do not know why SBCL requires so much heap. The lisp code itself isn't special, but some of the routines are really large because the original Fortran routine is really large.

     
  • Robert Dodier

    Robert Dodier - 2013-11-24
    • status: open --> wont-fix
     
  • Robert Dodier

    Robert Dodier - 2013-11-24

    Yeah, after searching for the error message, I see it has been encountered before. When I run Maxima with -l sbcl -X '--dynamic-space-size 1728', load(lapack) succeeds (although not with --dynamic-space-size 1024, and with 2048, Maxima won't start). I don't think there's anything to be done in Maxima about this so I'm closing it as wont-fix.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks