From: Robert S. <st...@la...> - 2006-06-16 20:37:37
|
Hello, In an attempt to investigate why 0.9.12 crashes when I start Gsharp from the CLIM desktop, I was given the advice (on #lisp) to use a version of SBCL compiled from CVS sources. I was also given the advice to enable the :sb-show, :sb-show-assem, and :sb-fluid features when compiling SBCL. However, this attempt failed with a CONTROL-STACK-EXHAUSTED error. Investigating further, I see that compiling with :sb-thread and :sb-futex works, but adding just :sb-fluid makes the build fail. Compiling with :sb-thread, :sb-futex, :sb-show, and :sb-show-assem seems to succeed, which lead me to believe that there might be a problem with :sb-fluid. This is all on GNU/Linux Ubuntu warty warthog. Just thought I'd let you know. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- |
From: Robert S. <st...@la...> - 2006-06-16 21:14:24
|
Robert Strandh writes: > Compiling with :sb-thread, :sb-futex, :sb-show, and :sb-show-assem > seems to succeed, ... I think I spoke to soon. Compiling with :sb-show and :sb-show-assem SEEMS to succeed, but the resulting system does not pass the tests. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- |
From: Nikodemus S. <nik...@ra...> - 2006-06-16 21:27:08
|
Robert Strandh <st...@la...> writes: > In an attempt to investigate why 0.9.12 crashes when I start Gsharp > from the CLIM desktop, I was given the advice (on #lisp) to use a > version of SBCL compiled from CVS sources. I was also given the > advice to enable the :sb-show, :sb-show-assem, and :sb-fluid features > when compiling SBCL. >From SBCL bugs: 206: ":SB-FLUID feature broken" (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks the build. ...so actually even getting the build to finish with :sb-fluid counts as an achievement. ,-) FWIW, I would me moderately surprised if :sb-show-assem or :sb-fluid were of any help in debugging such a crash. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Robert S. <st...@la...> - 2006-06-16 22:00:29
|
Nikodemus Siivola writes: > 206: ":SB-FLUID feature broken" > (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) > Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks > the build. Thanks. This probably shows that one cannot always trust advice given on #lisp. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- |
From: Robert S. <st...@la...> - 2006-06-16 22:11:03
|
Hello, Robert Strandh writes: > > In an attempt to investigate why 0.9.12 crashes when I start Gsharp > from the CLIM desktop, I was given the advice (on #lisp) to use a > version of SBCL compiled from CVS sources. I did recompile from sources, and I know have a better error message from SBCL when it crashes: Heap exhausted during allocation: 86368256 bytes available, 340537720 requested. Control stack guard page temporarily disabled: proceed with caution debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread #<THREAD {D8EE819}>: Control stack exhausted (no more space for function call frames). This is probably due to heavily nested or infinitely recursive function calls, or a tail call that SBCL cannot or has not optimized away. I have no idea why 340MB would be requested, but it seems plausible that the sum of the CLIM Desktop and Gsharp might be more than 86MB. The reason I think that is that the CLIM Desktop .core file is around 76MB. The CONTROL-STACK-EXHAUSTED is probably due to the fact that the CLIM desktop tries to start the CLIM debugger which then allocates more space, etc. Next, I'll try to figure out how to increase the heap size. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- |
From: Robert S. <st...@la...> - 2006-06-16 23:16:42
|
Hello again, Robert Strandh writes: > > Heap exhausted during allocation: 86368256 bytes available, 340537720 > requested. > ... > > I have no idea why 340MB would be requested, but it seems plausible > that the sum of the CLIM Desktop and Gsharp might be more than 86MB. > The reason I think that is that the CLIM Desktop .core file is around > 76MB. Reading the SBCL source code, I now understand that there must be something seriously wrong here (and not just a shortage of heap space). I now realize that someone/something is actually trying to allocate an object that requires 340MB, while there is "only" 86MB *remaining*. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- |
From: Nikodemus S. <nik...@ra...> - 2006-06-17 00:05:57
|
Robert Strandh <st...@la...> writes: > Robert Strandh writes: > > > > Heap exhausted during allocation: 86368256 bytes available, 340537720 > > requested. > > ... > > > > I have no idea why 340MB would be requested, but it seems plausible > > that the sum of the CLIM Desktop and Gsharp might be more than 86MB. > > The reason I think that is that the CLIM Desktop .core file is around > > 76MB. > > Reading the SBCL source code, I now understand that there must be > something seriously wrong here (and not just a shortage of heap > space). I now realize that someone/something is actually trying to > allocate an object that requires 340MB, while there is "only" 86MB > *remaining*. Quite. One thing you could try is (handler-bind ((storage-condition (c) (lambda (c) (sb-debug:backtrace)))) ...load-gsharp...) in order to see where the allocation is coming from. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Robert S. <st...@la...> - 2006-06-17 00:53:23
|
Nikodemus Siivola writes: > > Reading the SBCL source code, I now understand that there must be > > something seriously wrong here (and not just a shortage of heap > > space). I now realize that someone/something is actually trying to > > allocate an object that requires 340MB, while there is "only" 86MB > > *remaining*. > > Quite. One thing you could try is > > (handler-bind ((storage-condition (c) (lambda (c) (sb-debug:backtrace)))) > ...load-gsharp...) > > in order to see where the allocation is coming from. Thanks for helping figure this out. The problem was due to an object with large amounts of shared structure being printed while *print-circle* was nil. That object is a Gsharp buffer that is shown as part of an error message indicating that a particular slot is unbound. This error happens only when I start Gsharp from the CLIM desktop and not when I start it from McCLIM+SLIME, and I now have to figure out why. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- |