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

 
 

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

Submitted by:  Robert Dodier <robert_dodier>
Submitted on:  Wed 20 Nov 2013 07:31:53 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 21 Nov 2013 05:50:56 PM UTCcammStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1