GDB gives following info: getopt_clean_environment failes ..... getopt_init.c:60 Again nog problems with this hardware using 6.1, 6.2 RHL. (see also 21542) System is Siemens Fujitsu, Pentium III, 200 Mhz, 64Mb RAM, SCSI based with Tekram DC390U2W controller.
What was the patch command line that you used?
Even an empty one crashes it. I ran into this when trying to rebuild a dhcpcd that had similar signal 11 problems.
Try running a RAM test utility like memtest86. Spurious segfauls are most times hardware problems.
I will try to find it. just to be sure..., this systems now runs Redhat 6.1 & 6.2 without any problems for over a year now. (I can build kernels without problems (I 've read the Signal 11 FAQ)) the only time I have a problem is when booting from the Redhat 7.0 kernel & then run f.i. patch, dhcpcd and maybe others, but these two are the ones I ran into. the first when trying to beuild a new dhcpcd. And it is not at random addresses AFAIK, the four time I tried to run path from gdb it came with the same address.
I can't reproduce this here at all, with various different patch command lines, package builds, etc. This is with glibc-2.2-5. Is that what you're running? Could you give the actual backtrace that gdb shows?
[nico@linuxnb nico]$ gdb GNU gdb 5.0 Copyright 2000 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 "i386-redhat-linux". (gdb) exec patch (gdb) run Starting program: /usr/local/bin/patch (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x401aa567 in __getopt_clean_environment (env=0x0) at getopt_init.c:60 60 getopt_init.c: No such file or directory. (gdb) bt #0 0x401aa567 in __getopt_clean_environment (env=0x0) at getopt_init.c:60 #1 0x4010398d in init (argc=0, argv=0x0, envp=0x0) at ../sysdeps/unix/sysv/linux/init-first.c:100 #2 0x4000249b in _dl_boot () from /lib/ld-linux.so.1 (gdb) quit The program is running. Exit anyway? (y or n) y [nico@linuxnb nico]$ gdb GNU gdb 5.0 Copyright 2000 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 "i386-redhat-linux". (gdb) exec patch (gdb) run Starting program: /usr/local/bin/patch (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x401aa567 in __getopt_clean_environment (env=0x0) at getopt_init.c:60 60 getopt_init.c: No such file or directory. (gdb) bt #0 0x401aa567 in __getopt_clean_environment (env=0x0) at getopt_init.c:60 #1 0x4010398d in init (argc=0, argv=0x0, envp=0x0) at ../sysdeps/unix/sysv/linux/init-first.c:100 #2 0x4000249b in _dl_boot () from /lib/ld-linux.so.1 (gdb) quit The program is running. Exit anyway? (y or n) y [nico@linuxnb nico]$ Another queer thing, when running under su -, it doesn't SIGSEGV. When running as root from the console it does. To be sure it doesn't matter if you supply arguments or not..... I also run dhcpcd using gdb and that delivers: [root@linuxnb /root]# gdb GNU gdb 5.0 Copyright 2000 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 "i386-redhat-linux". (gdb) exec dhcpcd (gdb) run eth0 Starting program: /sbin/dhcpcd eth0 warning: shared library handler failed to enable breakpoint Program received signal SIGSEGV, Segmentation fault. 0x80545df in ?? () (gdb) bt #0 0x80545df in ?? () #1 0x8048e91 in ?? () #2 0x245c8b08 in ?? () Cannot access memory at address 0xec835356 (gdb) quit The program is running. Exit anyway? (y or n) y [root@linuxnb /root]# gdb GNU gdb 5.0 Copyright 2000 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 "i386-redhat-linux". (gdb) exec dhcpcd (gdb) run eth0 Starting program: /sbin/dhcpcd eth0 warning: shared library handler failed to enable breakpoint Program received signal SIGSEGV, Segmentation fault. 0x80545df in ?? () (gdb) bt #0 0x80545df in ?? () #1 0x8048e91 in ?? () #2 0x245c8b08 in ?? () Cannot access memory at address 0xec835356 (gdb) quit The program is running. Exit anyway? (y or n) y [root@linuxnb /root]# uname Linux [root@linuxnb /root]# uname -a Linux linuxnb.niconet.nl 2.2.17nb #1 Fri Dec 1 23:31:04 CET 2000 i586 unknown [root@linuxnb /root]# The memory test gave 0 errors after running for 5 hours and having completed about 11 and 1/2 passes. I've installed all patches issued until 27/11/2000. (this includes glibc-2.2.5) Currently I'm running the 2.2.17 kernel used for the above tests also as the kernel for the Redhat 6.2 environment. No troubles here.
#2 0x4000249b in _dl_boot () from /lib/ld-linux.so.1 ??? Umm.. [twaugh@meme ~]$ rpm -qf /lib/ld-linux.so.1 file /lib/ld-linux.so.1: No such file or directory [twaugh@meme ~]$ rpm -qf /lib/ld-linux.so.2 glibc-2.2-5 Looks like the upgrade to 7 didn't remove the old dynamic linker or something. What does 'rpm -qa | grep glibc' say?
Here is the new version listing: rpm -qf /lib/ld-linux.so.2 glibc-2.2-5 rpm -qf /lib/ld-linus.so.1 ld.so.1.9.5-13 rpm -qa | grep glibc compat-glibc-6.2-2.1.3.2 glibc-devel-2.2-5 glibc-2.2-5
(Upgrade procedure: Backup 6.2, upgrade using ISO's and have trouble, restore 6.2 on another disk, and that just works for now)
I don't understand why patch is using ld-linux.so.1: [twaugh@meme ~]$ ldd /usr/bin/patch libc.so.6 => /lib/libc.so.6 (0x4001f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) I notice that it's /usr/local/bin/patch that you're running, not /usr/bin/patch. What exactly is that?
Eh right. That solves this one. That's an old one when I had troubles upgrading a libc5 -> glibc environment. Appearantly this worked until this release. That solves this issue.. (I've removed all programs that were installed in /usr/local... that have copies in the /usr.. tree,) Thanks a bunch, I ve learned a lot from the experience. Still a question: where should ld.so be linked to? It is linked to the ld-linux-1 environment. I still have problems with DHCPCD as it accvio's but that one is statically linked. I'm not a gdb wizzard so I still have to find out where to get the symbols from etc. The problem has been described in # 21542, no reactions there though. Pump is no alternative because that doesn't allow me to update my firewall rules when an address change is needed, and it gives me another address on every boot. The patch matter is closed as far as I'm concerned. regards, Nico Baggus
I don't even have an ld.so link on my machine, so I guess it isn't needed.