shells/standalone-tcsh segfaults
Jarle Greipsland
has anyone else experienced problems with the
shells/standalone-tcsh package from pkgsrc? On my system it
dumps core quite early during startup. Could the fact that this
binary is linked statically be the problem? Any ideas?
Some more information below.
-jarle
gdb work/tcsh-6.17.00/tcsh
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "alpha--netbsd"...
(gdb) target core tcsh.core
Core was generated by `tcsh'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000012002fb68 in pendjob () at sh.proc.c:911
911 if (pcurrjob && (pcurrjob->p_flags & (PFOREGND | PSTOPPED)) == 0) {
(gdb) where
#0 0x000000012002fb68 in pendjob () at sh.proc.c:911
#1 0x0000000120004548 in process (catch=0) at sh.c:1855
#2 0x0000000120003dd0 in srcunit (unit=6, onlyown=0, hflg=0, av=0x0)
at sh.c:1625
#3 0x000000012000332c in srcfile (f=0x12010b2b4 "/etc/csh.cshrc", onlyown=0,
flag=0, av=0x0) at sh.c:1417
#4 0x0000000120002b30 in main (argc=0, argv=0x1ffffdb60) at sh.c:1226
(gdb) x/20i pendjob
0x12002fb4c <pendjob>: ldah gp,18(t12)
0x12002fb50 <pendjob+4>: lda gp,15500(gp)
0x12002fb54 <pendjob+8>: lda sp,-32(sp)
0x12002fb58 <pendjob+12>: stq ra,0(sp)
0x12002fb5c <pendjob+16>: stq fp,8(sp)
0x12002fb60 <pendjob+20>: mov sp,fp
0x12002fb64 <pendjob+24>: ldq t0,-30888(gp)
0x12002fb68 <pendjob+28>: ldq t0,0(t0)
0x12002fb6c <pendjob+32>: beq t0,0x12002fc3c <pendjob+240>
0x12002fb70 <pendjob+36>: ldq t0,-30888(gp)
0x12002fb74 <pendjob+40>: ldq t0,0(t0)
0x12002fb78 <pendjob+44>: ldq t1,24(t0)
0x12002fb7c <pendjob+48>: lda t0,258
0x12002fb80 <pendjob+52>: and t1,t0,t0
0x12002fb84 <pendjob+56>: bne t0,0x12002fc3c <pendjob+240>
0x12002fb88 <pendjob+60>: ldq t0,-30888(gp)
0x12002fb8c <pendjob+64>: ldq t0,0(t0)
0x12002fb90 <pendjob+68>: stq t0,24(fp)
0x12002fb94 <pendjob+72>: br 0x12002fba4 <pendjob+88>
0x12002fb98 <pendjob+76>: ldq t0,24(fp)
(gdb) p pcurrjob
$1 = (struct process *) 0x0
# cat -n work/tcsh-6.17.00/sh.proc.c | grep -B 1 -A 10 'pendjob(void)'
906 void
907 pendjob(void)
908 {
909 struct process *pp, *tp;
910
911 if (pcurrjob && (pcurrjob->p_flags & (PFOREGND | PSTOPPED)) == 0) {
912 pp = pcurrjob;
913 while (pp->p_procid != pp->p_jobid)
914 pp = pp->p_friends;
915 xprintf("[%d]", pp->p_index);
916 tp = pp;
917 do {
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Jarle Greipsland
> has anyone else experienced problems with the
> shells/standalone-tcsh package from pkgsrc? On my system it
> dumps core quite early during startup. Could the fact that this
> binary is linked statically be the problem? Any ideas?
linked binary from this package runs just fine. So the static
vs. dynamic build seems to make a difference. Has something
happened recently with the compiler or linker?
-jarle
Jarle Greipsland
> Jarle Greipsland <jarle.gr...@uninett.no> writes:
> > has anyone else experienced problems with the
> > shells/standalone-tcsh package from pkgsrc? On my system it
> > dumps core quite early during startup. Could the fact that this
> > binary is linked statically be the problem? Any ideas?
> linked binary from this package runs just fine. So the static
> vs. dynamic build seems to make a difference. Has something
> happened recently with the compiler or linker?
It's a linker problem. I compiled the standalone-tcsh package in
the usual way, but removed the resulting binary, and performed
just the final link command with a linker (and corresponding
libbfd.so.9 shared object) from a 5.1_RC?-something system. The
resulting statically linked binary runs just fine.
So, something has changed in -current with regards to the linker
or the BFD library -- something that breaks static linking on the
NetBSD/alpha platform. Does this ring any bells?
-jarle
--
"Does the name Pavlov ring a bell?"