Bug 168451 - xmaxima crashes entire X session when quitting
xmaxima crashes entire X session when quitting
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: maxima (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-16 02:46 EDT by Alex Lancaster
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-23 15:01:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alex Lancaster 2005-09-16 02:46:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Galeon/1.3.21

Description of problem:
xmaxima: logging out (or even just killing the xmaxima window) logs out of the entire X session.

Some earlier reports were filed here in bug #167870.



Version-Release number of selected component (if applicable):
maxima-gui-5.9.1-4.fc4

How reproducible:
Always

Steps to Reproduce:
1. Start "xmaxima" from the command line
2. Quit xmaxima from the menu.
  

Actual Results:  X session dies completely.

Expected Results:  xmaxima should have exited normally.

Additional info:
Comment 1 Andre Robatino 2005-09-16 02:59:46 EDT
  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.
Comment 2 Rex Dieter 2005-09-16 14:19:02 EDT
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).

Comment 3 Andre Robatino 2005-09-17 02:36:39 EDT
  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.
Comment 4 Kevin Kofler 2005-09-22 06:23:03 EDT
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).
Comment 5 Rex Dieter 2005-09-22 07:51:58 EDT
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. 
Comment 6 Kevin Kofler 2005-09-22 07:58:14 EDT
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.
Comment 7 Rex Dieter 2005-09-22 10:03:59 EDT
Taking back, got maxima-5.9.1.9rc1 built, and bug is (apparently) gone.  Please
re-open if your experience is different.
Comment 8 Robin 2005-09-22 14:22:11 EDT
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.  
Comment 9 Gérard Milmeister 2005-09-22 15:37:43 EDT
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.
Comment 10 Rex Dieter 2005-09-22 16:25:46 EDT
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.
Comment 11 Gérard Milmeister 2005-09-22 17:44:30 EDT
(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.
Comment 12 Rex Dieter 2005-09-23 09:36:29 EDT
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.  ???
Comment 13 Rex Dieter 2005-09-23 15:01:50 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.