bugGNU Common Lisp - Bugs: bug #40646, '(NIL) apparently clobbered by...

 
 

bug #40646: '(NIL) apparently clobbered by loading compiled code (Maxima share stuff)

Submitter:  Robert Dodier <robert_dodier>
Submitted:  Wed 20 Nov 2013 07:31:53 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 21 Nov 2013 07:31:18 PM UTC, comment #2: 

Thanks, Camm. You are right on the mark. Removing the call to si::reset-stack-limits does indeed fix the problem. I am certain it is unneeded. It is present in the oldest version of Maxima which I have at hand (version 5.0, with macsys.lisp dated 1992); I'm guessing it was a performance hack.

Robert Dodier <robert_dodier>
Thu 21 Nov 2013 05:50:56 PM UTC, comment #1: 

Thanks for your report!  If you eliminate the call to #'si::reset-stack-limits in macsys.c, this will fix the problem.

Perhaps we could discuss how this line got there.  gcl uses it in its top-level to set the range of C stack to be searched by the garbage collector, among other things.  The idea here is that all lisp objects on the C stack are south of the address present in top-level, which never exits.  In other words, all calls are children of top-level. 

I ran your code through gdb, and this reset occurred in the middle somewhere, setting the C stack top below objects you had already initialized, causing them to fail to be marked and then collected.

Take care,

Camm Maguire <camm>
Group administrator
Wed 20 Nov 2013 07:31:53 AM UTC, original submission:  

With GCL 2.6.10, I find that '(NIL) which is used as an EOF marker is apparently clobbered by loading compiled code via defsystem. For example:

  $ maxima -l gcl --batch-string='load(draw); 123;'

causes Maxima to compile and load the draw package (using its system definition share/draw/draw.system). Then it is supposed to print the number 123, but after reading 123 it barfs out an error:

  Error in MACSYMA-TOP-LEVEL [or a callee]: #<FREE OBJECT 0205a610> is not of type CHARACTER.

I have determined that this is due to calling UNREAD-CHAR in DBM-READ (currently at line 367 in src/mdebug.lisp) with NEXT-CHAR equal to the aforementioned #<FREE OBJECT 0205a610>.

Now #<FREE OBJECT 0205a610> is supposed to be '(NIL) so that a different branch is supposed to be taken. There is a slight logic error in DBM-READ (if the EOF marker is something other than NIL or '(NIL), it shouldn't call UNREAD-CHAR) but the main problem is that '(NIL) has been clobbered.

Same command line works as expected (no error) with other varieties e.g. Clisp, Clozure CL.

Second time the command line is executed, GCL loads already-compiled code and no error is observed.

Robert Dodier <robert_dodier>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by camm (Posted a comment)
  • -email is unavailable- added by robert_dodier (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-11-21 camm StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code