Subject: Re: Maxima-5.5-beta and dynamic shared lib links
From: Richard Fateman
Date: Fri, 23 Feb 2001 13:04:30 -0800
Sorry I can't help with this. I think there is a problem
with GCL, and I don't know about its implementation at all.
RJF
Camm Maguire wrote:
>
> 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