Bug 21543 - Signal 11, during handling of options.
Signal 11, during handling of options.
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: patch (Show other bugs)
7.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-30 16:37 EST by Nico Baggus
Modified: 2007-04-18 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-12-05 15:43:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nico Baggus 2000-11-30 16:37:27 EST
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.
Comment 1 Tim Waugh 2000-12-01 09:04:00 EST
What was the patch command line that you used?
Comment 2 Nico Baggus 2000-12-01 15:22:01 EST
Even an empty one crashes it. I ran into this when trying to rebuild a 
dhcpcd that had similar signal 11 problems.
Comment 3 Daniel Roesen 2000-12-01 19:59:40 EST
Try running a RAM test utility like memtest86. Spurious segfauls are most times
hardware problems.
Comment 4 Nico Baggus 2000-12-02 15:30:38 EST
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.

Comment 5 Tim Waugh 2000-12-02 15:58:42 EST
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?
Comment 6 Nico Baggus 2000-12-03 15:49:03 EST
[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.
Comment 7 Tim Waugh 2000-12-04 06:09:04 EST
#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?
Comment 8 Nico Baggus 2000-12-04 17:17:29 EST
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


Comment 9 Nico Baggus 2000-12-04 17:20:05 EST
(Upgrade procedure:

Backup 6.2, upgrade using ISO's and have trouble, restore 6.2
on another disk, and that just works for now)
Comment 10 Tim Waugh 2000-12-05 10:07:16 EST
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?
Comment 11 Nico Baggus 2000-12-05 15:43:11 EST
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
Comment 12 Tim Waugh 2000-12-05 19:23:18 EST
I don't even have an ld.so link on my machine, so I guess it isn't needed.

Note You need to log in before you can comment on or make changes to this bug.