Debian Bug report logs - #11387
libc6-dbg causes core dump in runtime startup

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bradley Bosch <brad@lachman.com>

To: submit@bugs.debian.org

Subject: libc6-dbg causes core dump in runtime startup

Date: Sat, 19 Jul 1997 12:00:18 -0500 (CDT)

Package: libc6-dbg
Version: 2.0.4-1

This version of libc6-dbg doesn't seem to work at all for me.  When I
run a binary linked with it, I get a segmentation fault before main
even gets called.  Did I do something stupid?

This problem was observed on a Debian 1.3.1 system with some (libc6 and gcc)
packages from the current hamm directory.

To make sure it was the library and not my code, I built the hello
package from source with libc6, then re-linked with the debugging
library like so:

gcc -g -o hello -lc_g hello.o version.o getopt.o getopt1.o

gdb hello

(gdb) run
Starting program: /home/brad/debian/hello/hello-1.3/hello 

Program received signal SIGSEGV, Segmentation fault.
0x8050257 in __getopt_clean_environment () at getopt_init.c:66
getopt_init.c:66: No such file or directory.
(gdb) bt
#0  0x8050257 in __getopt_clean_environment () at getopt_init.c:66
#1  0x804bf9e in init (argc=1, argv=0xbffffb3d, envp=0x0)
    at ../sysdeps/unix/sysv/linux/init-first.c:77
#2  0x804c001 in __libc_init_first (arg=0x1)
    at ../sysdeps/unix/sysv/linux/init-first.c:95
(gdb) 

Thanks,

--Brad Bosch
brad@lachman.com

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jim Pick <jim@jimpick.com>

To: Bradley Bosch <brad@lachman.com>, 11387@bugs.debian.org

Cc: submit@bugs.debian.org

Subject: Re: Bug#11387: libc6-dbg causes core dump in runtime startup

Date: Tue, 09 Sep 1997 19:54:11 -0700

[Message part 1 (text/plain, inline)]

> Package: libc6-dbg
> Version: 2.0.4-1
> 
> This version of libc6-dbg doesn't seem to work at all for me.  When I
> run a binary linked with it, I get a segmentation fault before main
> even gets called.  Did I do something stupid?
> 
> This problem was observed on a Debian 1.3.1 system with some (libc6 and gcc)
> packages from the current hamm directory.
> 
> To make sure it was the library and not my code, I built the hello
> package from source with libc6, then re-linked with the debugging
> library like so:
> 
> gcc -g -o hello -lc_g hello.o version.o getopt.o getopt1.o
> 
> gdb hello
> 
> (gdb) run
> Starting program: /home/brad/debian/hello/hello-1.3/hello 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x8050257 in __getopt_clean_environment () at getopt_init.c:66
> getopt_init.c:66: No such file or directory.
> (gdb) bt
> #0  0x8050257 in __getopt_clean_environment () at getopt_init.c:66
> #1  0x804bf9e in init (argc=1, argv=0xbffffb3d, envp=0x0)
>     at ../sysdeps/unix/sysv/linux/init-first.c:77
> #2  0x804c001 in __libc_init_first (arg=0x1)
>     at ../sysdeps/unix/sysv/linux/init-first.c:95
> (gdb) 
> 
> Thanks,
> 
> --Brad Bosch
> brad@lachman.com

I think the problem is that gcc automatically uses libc if you don't
tell it not to.  Using the -v option to gcc will show you what it is doing:


hello-1.3$ gcc -v -g -o hello -lc_g hello.o version.o getopt.o getopt1.o
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.2/specs
gcc version 2.7.2.2
 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello /usr/lib/crt1.o 
/usr/lib/crti.o /usr/lib/gcc-lib/i486-linux/2.7.2.2/crtbegin.o 
-L/usr/lib/gcc-lib/i486-linux/2.7.2.2 -lc_g hello.o version.o getopt.o 
getopt1.o -lgcc -lc -lgcc /usr/lib/gcc-lib/i486-linux/2.7.2.2/crtend.o 
/usr/lib/crtn.o
hello-1.3$ ldd ./hello
        libc.so.6 => /lib/libc.so.6 (0x40010000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
hello-1.3$ ./hello
Segmentation fault (core dumped)


So you need to tell gcc not to link in libc (shown by -lc in the output
listed above).  Using -lc_g -lgcc -nodefaultlibs should do this.  Note 
that the order in which the libs are referenced is important.


hello-1.3$ gcc -v -g -o hello hello.o version.o getopt.o getopt1.o -lc_g -lgcc 
-nodefaultlibs
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.2/specs
gcc version 2.7.2.2
 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello /usr/lib/crt1.o 
/usr/lib/crti.o /usr/lib/gcc-lib/i486-linux/2.7.2.2/crtbegin.o 
-L/usr/lib/gcc-lib/i486-linux/2.7.2.2 hello.o version.o getopt.o getopt1.o 
-lc_g -lgcc /usr/lib/gcc-lib/i486-linux/2.7.2.2/crtend.o /usr/lib/crtn.o
hello-1.3$ ldd ./hello
        statically linked (ELF)
hello-1.3$ ./hello
Hello, world!

One more tip:

Make a symlink from /home/geyer/Software/glibc-2.0.4 to where you have 
the glibc source unpacked (ugly, eh?) - that way gdb can find the source 
files.

I just figured this out today.  So it's not really a bug.  Hope it helps.


Cheers,

 - Jim

[Message part 2 (application/pgp-signature, inline)]

Message #18 received at 11387-quiet@bugs.debian.org (full text, mbox, reply):

From: "Bradley A. Bosch" <brad@lachman.com>

To: Jim Pick <jim@jimpick.com>

Cc: 11387-quiet@bugs.debian.org

Subject: Re: Bug#11387: libc6-dbg causes core dump in runtime startup

Date: Wed, 10 Sep 1997 12:15:39 -0500 (CDT)

Jim Pick writes:
 > 
 > So you need to tell gcc not to link in libc (shown by -lc in the output
 > listed above).  Using -lc_g -lgcc -nodefaultlibs should do this.  Note 
 > that the order in which the libs are referenced is important.
 > 

Is this how it is supposed to work?  I admit that I don't understand
the low level details of the linker or the libraries, but why would an
extra library which is not required cause a problem?  All symbols
should have been resolved by the time the standard C library was read.
What is getting linked in from this library?

Is this required use of -nodefaultlibs with -lc_g documented
somewhere?  If not, please consider my bug report a documentation
problem.

Thanks.

--Brad Bosch

Send a report that this bug log contains spam.