Subject: Maxima-5.5-beta and dynamic shared lib links
From: Camm Maguire
Date: 23 Feb 2001 15:39:54 -0500
Greetings! I'm upgrading the Debian maxima package to 5.5-beta, and
am running into the same shared-library link problems as before. This
time, I've found some time to detail what's going on a bit more
clearly, so hopefully this will help.
I've now produced two saved_maxima executables, one 5.5-beta compiled
with -g, and one using the current cvs trees for gcl and maxima
compiled as per default, both of which run successfully on 3, and
segfault on 4 of our Debian 2.2 "aka potato" boxes, all of which share
an NFS home filesystem. The problem is the same in all cases: on
startup,
PRINTstream->sm.sm_object0->s.s_dbind->sm.sm_object1->sm.sm_fp->_fileno
is correctly set to stdout (1) on the boxes where it works, and
garbage where it segfaults. The program segfaults when trying to
first write to stdout. (Actually, the whole sm_fp FILE structure is
bogus.)
This setup must be preallocated on the stack or some such, as this
condition holds even when breaking in gdb at the address of the first
assembly statement in init of the executable. Furthermore, on
checking the memory maps loaded by the process, (/proc/<pid>/maps:),
all working cases show the following:
08048000-08485000 r-xp 00000000 03:03 88802 /usr/lib/maxima-5.5/src/saved_maxima_debug
08485000-086fe000 rw-p 0043c000 03:03 88802 /usr/lib/maxima-5.5/src/saved_maxima_debug
086fe000-087af000 rwxp 00000000 00:00 0
40000000-40012000 r-xp 00000000 03:03 34721 /lib/ld-2.1.3.so
40012000-40013000 rw-p 00011000 03:03 34721 /lib/ld-2.1.3.so
40013000-40014000 rwxp 00000000 00:00 0
40019000-400ee000 r-xp 00000000 03:03 34724 /lib/libc-2.1.3.so
400ee000-400f2000 rw-p 000d4000 03:03 34724 /lib/libc-2.1.3.so
400f2000-400f6000 rw-p 00000000 00:00 0
400f6000-40112000 r-xp 00000000 03:03 34901 /lib/libm-2.1.3.so
40112000-40113000 rw-p 0001b000 03:03 34901 /lib/libm-2.1.3.so
bfff2000-c0000000 rwxp ffff3000 00:00 0
whereas the failing cases show
08048000-08477000 r-xp 00000000 09:00 128542 /fix/c/home/camm/saved_maxima_debug
08477000-086ef000 rw-p 0042e000 09:00 128542 /fix/c/home/camm/saved_maxima_debug
40000000-40012000 r-xp 00000000 08:02 174764 /lib/ld-2.1.3.so
40012000-40013000 rw-p 00011000 08:02 174764 /lib/ld-2.1.3.so
40013000-40014000 rwxp 00000000 00:00 0
4001c000-400f1000 r-xp 00000000 08:02 174798 /lib/libc-2.1.3.so
400f1000-400f5000 rw-p 000d4000 08:02 174798 /lib/libc-2.1.3.so
400f5000-400f9000 rw-p 00000000 00:00 0
400f9000-40115000 r-xp 00000000 08:02 174815 /lib/libm-2.1.3.so
40115000-40116000 rw-p 0001b000 08:02 174815 /lib/libm-2.1.3.so
bfffd000-c0000000 rwxp ffffe000 00:00 0
All machines have identical ldso and libc6 packages installed.
I haven't yet had time to understand the sfaslelf.c and/or rsym_elf.c,
which is where I think this is getting setup. I would greatly
appreciate suggestions from those much more knowledgeable than me on
this list! Unfortunately, my test case is not on a public network. I
haven't yet discovered what aspect of these machines is causing the
different loading, so I cannot guarantee reproducing this situation on
another system, though this behavior does persist on each execution
of saved_maxima here. Any suggestions of what to try would be most
helpful. I'm pretty decent with C and a debugger, but don't know
about elf formats, etc.
Thanks!
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah