I called taylor() with the wrong argument order (putting the R third instead of second), and that causes a segfault if done twice:
(%i1) taylor(exp(R), 0, R, 10);
Maxima encountered a Lisp error:
Error in PROGN [or a callee]: Caught fatal error [memory may be damaged]
Automatically continuing.
To reenable the Lisp debugger set *debugger-hook* to nil.
(%i2) taylor(exp(R), 0, R, 10);
Segmentation fault (core dumped)
This is with
Maxima version: 5.12.0
Maxima build date: 3:18 5/23/2007
host type: i686-pc-linux-gnu
lisp-implementation-type: GNU Common Lisp (GCL)
lisp-implementation-version: GCL 2.6.7
(it's the Ubuntu 5.12.0-1ubuntu1 package for Ubuntu 7.10 recompiled for Ubuntu 7.04.)
-Sanjoy
Logged In: YES
user_id=1797506
Originator: NO
(%i19) taylor(exp(R), 0, R, 10);
Variable of expansion cannot be a number: 0
-- an error. To debug this try debugmode(true);
Logged In: YES
user_id=929336
Originator: NO
I don't agree that this bug has been fixed, thus I'm reopening it for now. I can reproduce it with 5.13.0 under gcl. Also I don't recall any cvs commit messages since the release, that I'd expect to affect this.
@dgildea: Could you please be more verbose why you think this bug has been fixed. What was the cvs revision? What was the build_info for the session, that you pasted into your message?
@all: This bug seems to be lisp specific. clisp doesn't crash, but it still gives a lisp error, which might be considered a bug in maxima. gcl does crash with a segfault the second time. Perhaps this is also a bug in gcl? Is it ok, that maxima is able to crash gcl?
Logged In: YES
user_id=929336
Originator: NO
I take the last message back. I didn't realize that it was a very recent commit, because for some reason I didn't get the commit mail.
For the record: The bug was fixed in src/hayat.lisp revision 1.26, Thu Aug 30 21:30:40 2007 UTC
Sorry for the noise.