Bug 168451

  As I mentioned in bug #167870, I can avoid killing the X session by running
xmaxima in the foreground from a shell window and killing it with Ctrl-C.  Don't
know any other way to avoid the problem.

As before...

Andre, 

In general, no single application should be able to take down an X session. 
Further, xmaxima doesn't kill X (for me) when run on RH9, RHEL4, Fedora Core 3. 

However, I can confirm the crash on FC4, my ~/.xsession-errors (appended at the
end) is mostly unhelpful.  Considering that xmaxima is simply a wish(tk) script,
I'd venture this to be either a tk/tcl or X server bug, specific to Fedora Core 4.

That being said, a new version is coming soon (maxima-5.9.2), and on testing the
pre-release (maxima-5.9.1.9rc1), it doesn't crash like 5.9.1.  I'll see about
pushing out 5.9.1.9rc1 for FC4 (since a non-crashing pre-release is better than
the current situation).

---------------

  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2003
--------------------------------------------------------------

Maxima 5.9.1 http://maxima.sourceforge.net
Using Lisp CLISP 2.35 (2005-08-29)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
This is a development version of Maxima. The function bug_report()
provides bug reporting information.
(%i1) kicker: sighandler called
*** kdesktop got signal 15 (Exiting)
end from FAM server connection
X connection to :0.0 broken (explicit kill or server shutdown).

  Not necessarily - a usability problem such as this one is still less serious
than a mathematical bug, since this problem isn't hidden, and can be worked
around (athough it's a pain).  Also, if the core problem is with some
lower-level component, it's better to track down and fix that instead.  Someone
who knows what they're doing should be able to take the xmaxima script and find
out how the X shutdown is being triggered.

A complete X11 crash is a very annoying bug. It can lead to severe data loss.

For the record, this is happening for me as well. I don't have any details to 
provide though (at least not yet, just ask me if you need me to reproduce the 
problem and get some logs this time).

As mentioned, in general, a tk/wish application should not be able to take down
an X session.  xmaxima doesn't kill X (for me) when run on RH9, RHEL4, or FC3. 
Considering that xmaxima is simply a wish(tk) script, I'd venture this to be
either a tk/tcl or X server bug, specific to Fedora Core 4.

Re-assigning FE-maxima => FC4-tk. 

Well, there was a bug in xmaxima at one point where it would kill everything 
running on the system by mistake. See this thread (which I found with a search 
engine):
http://www.math.utexas.edu/pipermail/maxima/2002/003000.html

While I guess that bug has already been fixed by now, it does show that there 
may be something fishy going on inside xmaxima itself.

Taking back, got maxima-5.9.1.9rc1 built, and bug is (apparently) gone.  Please
re-open if your experience is different.

This issue has been posted on the maxima bugtracker.

http://sourceforge.net/tracker/index.php?func=detail&aid=1276259&group_id=4933&atid=104933

It seems that maxima sends a 'kill -TERM -1' command on exit.

This needs to be fixed as I was trying xmaxima and I lost allot of work.  

It seems this is a problem with the clisp runtime.
The maxima runtime returns its pid to the tk frontend
by calling a lisp function (getpid) (see server.lisp).
This function is defined as:
(deff getpid (symbol-function
              ;; Decide at load time which function to use.
              (or (and (memq :unix *features*)
                       (find-symbol "PROGRAM-ID" "SYS"))
                  'getpid-from-environment)))
i.e., first as (find-symbol "PROGRAM-ID" "SYS"), however there
is no such symbol so the fallback is getpid-from-environment. This
unrolls until we get to maxima-getenv in init-cl.lisp which is
called with the argument "PID" and would return the value of
the environment variable PID which is assumed to contain the pid of
the current process which it doesn't. An -1 is returned and kill with pid -1
kills all processes.

Interesting, in maxima-5.9.1.9rc1, that bit of code is:

#+clisp
(deff getpid (symbol-function
              ;; Decide at load time which function to use.
              (or (and (memq :unix *features*)
                       (or (find-symbol "PROCESS-ID" "SYS")
                           (find-symbol "PROGRAM-ID" "SYS")))
                  'getpid-from-environment)))


I'd assume that the added (find-symbol "PROCESS-ID" "SYS") helps make it work.

(In reply to comment #10)
> I'd assume that the added (find-symbol "PROCESS-ID" "SYS") helps make it work.

Yes the function process-id exists in clisp, maybe program-id was in
earlier version of clisp!?
Neither function is in ANSI-CL.

Reopening... Turns out the maxima-5.9.1.9rc1 (fc4) update that fixes this got
hung up in the FE buildsystem(*).  I've resubmitted it just now, so hopefully we
can finally get a resolution soon.

(*) the development/fc5 build finished fine.  ???

Yay.

1335 (maxima): Build on target 4 succeeded.  Build logs may be found at
http://buildsys.fedoraproject.org/logs/4/1335-maxima-5.9.1.9rc1-4.fc4/

Coming soon to a repo near you.