Annoyed by the fact http://bugs.gentoo.org/show_bug.cgi?id=82000 is not solved on ppc or ~ppc I added sci-mathematics/maxima ~x86 in my /etc/portage/package.keywords and emerged maxima-5.9.1-r5. I can now start xmaxima without problems (5.9.1 complains about not finding the documentation and exit immediately). The problem is that when I quit xmaxima my xserver is shutdown as well and I am back to the kdm logging screen. Reproducible: Always Steps to Reproduce: 1.Add sci-mathematics/maxima ~x86 to /etc/portage/package.keywords 2.emerge maxima with the following use flags: +auctex +clisp (-cmucl) -emacs -gcl +tetex 3.start xmaxima 4. quit xmaxima Actual Results: My Xserver died. Expected Results: quitted gracefully without taking my Xsession away with it. merge info Portage 2.0.51.22-r3 (default-linux/ppc/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.12-gentoo-r6 ppc) ================================================================= System uname: 2.6.12-gentoo-r6 ppc 7450, altivec supported Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=7450 -pipe -maltivec -mabi=altivec -mpowerpc-gfxopt -fsigned-char -frename-registers -fweb -fno-strict-aliasing" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=7450 -pipe -maltivec -mabi=altivec -mpowerpc-gfxopt -fsigned-char -frename-registers -fweb -fno-strict-aliasing" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.vic.keypoint.com.au http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo http://mirror.tucdemonic.org/gentoo/" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="ppc X a52 aac aalib alsa altivec arts berkdb bitmap-fonts cairo cddb cdf cdparanoia cdr crypt cups curl dts dv dvd dvdr dvdread emboss encode esd f77 fam fbcon ffmpeg flac foomaticdb fortran gd gdbm ggi gif gpm graphviz gstreamer gtk gtk2 hal ieee1394 imagemagick imlib imlib2 ipv6 java jbig jpeg jpeg2k kde kdexdeltas lcms libwww live lzo mad mikmod mjpeg motif mp3 mpeg ncurses netcdf network nls nptl ogg oggvorbis openexr opengl oss pam pdflib perl plotutils png ppds python qt rdesktop readline samba sdl slang slp spell ssl szip tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode vorbis wmf xine xml xml2 xmms xv xvid zeroconf zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
Actually after applying the symlink fix from Bug 82000 I have the same problem with xmaxima 5.9.1. I cannot find any log of what is wrong. I remember trying maxima some time ago probably 5.9.0 and it didn't have these problems.
Has the ppc keyword been dropped accidentally? Couldn't find anythin in the ChangeLog...
I have the same problem on AMD64 using clisp (instead of the default gcl) as a backend. I didn't test with gcl.
Yes, xmaxima doesn't take the X session down on exiting if gcl is used as the backend (AMD64)
I tried the gcl backend on ppc and on my system at least xmaxima effectively doesn't take X down. The problem is that maxima segfault on the comand line which means that all I have is an empty xmaxima window with no prompt.
I tracked down the clisp crash problem, and have a couple of patches to fix it. 1. maxima has clisp-specific code to get pid, which is broken for recent versions of clisp with maxima-5.9.1 -- it instead returns instead '-1' 2. the maxima CMkill function checks only that pid is an int -- it accepts '-1' as a valid pid Put the two together, and you have the reported problem -- SIGTERM sent to every process, and killing everything the user running maxima has permissions to kill. The first issue has been fixed since maxima-5.9.2 (http://cvs.sourceforge.net/viewcvs.py/maxima/maxima/src/server.lisp?rev=1.11&view=log) This is enough to prevent xmaxima from going trigger-happy in this case, but I like to be conservative and added a second patch that makes CMkill refuse to kill pid <= 1.
Created attachment 84107 [details, diff] fix getpid function to work with modern versions of clisp
Created attachment 84108 [details, diff] maxima CMkill function checks for pid > 1
Created attachment 84109 [details] updated maxima ebuild that applies the above patches
Patches committed after nerdboy from sci team tried and approved. I left the ebuild rev at r5 so that x86 maxima users happily using gcl or cmucl won't have to rebuild unnecessarily.
