[uClibc] Why my share-linked code always segment fault before the main is reached?

cwang cwang at redsonic.com
Tue Nov 2 07:20:42 UTC 2004


Hi:

I have use uClibc for a long time, from uClibc-0.9.19 to uClibc-0.9.26. But
there is one problem always confuse me.

Now I'm using the toolchain extracted and build from uclibc.org, the
compiled toolchain is copied into /opt/toolchain_i386.

I use the following command line to compile my program:
/opt/toolchain_i386/i386-linux-uclibc/bin/gcc -Wall -g -c -o hello.o hello.c
/opt/toolchain_i386/i386-linux-uclibc/bin/gcc -o hello hello.o

And hello.c is one 'printf' program. The generated binary 'hello' works ok.
And ldd hello shows:
        libc.so.0 => /usr/i386-linux-uclibc/lib/libc.so.0 (0xbf579000)
        ld-uClibc.so.0 => /usr/i386-linux-uclibc/lib/ld-uClibc.so.0
(0x79d000)

But when I do this on a bigger program, it always cause the code segment
fault. For example, I copy xmlparse.c xmlrole.c xmltok_impl.c xmltok_ns.c
and the related header files from expat-1.95.8 into lib subdirectory, and
copy elements.c from expat-1.95.8/examples. And use the following command
line to compile it:

/opt/toolchain_i386/i386-linux-uclibc/bin/gcc -Wall -g -DHAVE_EXPAT_CONFIG_H
 -I. -Ilib -c -o elements.o elements.c
/opt/toolchain_i386/i386-linux-uclibc/bin/gcc -Wall -g -DHAVE_EXPAT_CONFIG_H
 -I. -Ilib -c -o lib/xmlparse.o lib/xmlparse.c
/opt/toolchain_i386/i386-linux-uclibc/bin/gcc -Wall -g -DHAVE_EXPAT_CONFIG_H
 -I. -Ilib -c -o lib/xmltok.o lib/xmltok.c
/opt/toolchain_i386/i386-linux-uclibc/bin/gcc -Wall -g -DHAVE_EXPAT_CONFIG_H
 -I. -Ilib -c -o lib/xmlrole.o lib/xmlrole.c
/opt/toolchain_i386/i386-linux-uclibc/bin/ar r lib/libexpat.a lib/xmlparse.o
lib/xmltok.o lib/xmlrole.o
/opt/toolchain_i386/i386-linux-uclibc/bin/ranlib lib/libexpat.a
/opt/toolchain_i386/i386-linux-uclibc/bin/gcc -o elements elements.o
lib/libexpat.a
/opt/toolchain_i386/i386-linux-uclibc/bin/gcc -o elements1 elements.o
lib/xmlparse.o lib/xmltok.o lib/xmlrole.o

So I get two executables: 'elements' and 'elements1', when I try to run
them, both of them segment fault!

Here is the output of 'strace ./elements':

execve("./elements", ["./elements"], [/* 38 vars */]) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0)
= 0xbf541000
readlink("/lib/ld-uClibc.so.0", "/usr/i386-linux-uclibc/lib/ld-uClibc.so.0",
1024) = 41
open("/usr/i386-linux-uclibc/lib/libc.so.0", O_RDONLY) = 3
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0)
= 0xbf540000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\261"..., 4096)
= 4096
old_mmap(NULL, 237568, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xbf506000
old_mmap(0xbf506000, 195247, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0xbf506000
old_mmap(0xbf536000, 2952, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x30000) = 0xbf536000
old_mmap(0xbf537000, 36796, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xbf537000
close(3)                                = 0
mprotect(0xbf506000, 195247, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
munmap(0xbf540000, 4096)                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0)
= 0xbf540000
write(2, "\n", 1
)                       = 1
write(2, "./elements", 10./elements)              = 10
write(2, ": ", 2: )                       = 2
munmap(0xbf540000, 4096)                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0)
= 0xbf540000
write(2, "symbol \'", 8symbol ')                = 8
write(2, "__stdout", 8__stdout)                 = 8
write(2, "\': ", 3': )                     = 3
munmap(0xbf540000, 4096)                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0)
= 0xbf540000
write(2, "can\'t resolve symbol\n", 21can't resolve symbol
) = 21
munmap(0xbf540000, 4096)                = 0
mprotect(0xbf506000, 195247, PROT_READ|PROT_EXEC) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
brk(0x806ce14)                          = 0x806ce14
brk(0x806d000)                          = 0x806d000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

I also run the following commands in the expat-1.95.8 source tree:

PATH=/opt/toolchain_i386/i386-linux-uclibc/bin/:$PATH
./configure --prefix=/usr/i386-linux-uclibc/
CC=/opt/toolchain_i386/i386-linux-uclibc/bin/gcc
PATH=/opt/toolchain_i386/i386-linux-uclibc/bin:$PATH make

Then run the generated xmlwf/xmlwf, it segment fault too.
Here is the output of 'strace xmlwf/xmlwf':


execve("xmlwf/xmlwf", ["xmlwf/xmlwf"], [/* 39 vars */]) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0)
= 0xbf559000
readlink("/lib/ld-uClibc.so.0", "/usr/i386-linux-uclibc/lib/ld-uClibc.so.0",
1024) = 41
open("/usr/i386-linux-uclibc/lib/libc.so.0", O_RDONLY) = 3
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0)
= 0xbf558000
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\261"..., 4096)
= 4096
old_mmap(NULL, 237568, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xbf51e000
old_mmap(0xbf51e000, 195247, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0xbf51e000
old_mmap(0xbf54e000, 2952, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x30000) = 0xbf54e000
old_mmap(0xbf54f000, 36796, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xbf54f000
close(3)                                = 0
mprotect(0xbf51e000, 195247, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
munmap(0xbf558000, 4096)                = 0
mprotect(0xbf51e000, 195247, PROT_READ|PROT_EXEC) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
brk(0x8064fc8)                          = 0x8064fc8
brk(0x8065000)                          = 0x8065000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

But if I link it static, the binary works fine.

So I think it might be a bug in /usr/i386-linux-uclibc/lib/ld-uClibc.so.0.
Or I use wrong command line to build the binary?

Charles  Nov 2.




More information about the uClibc mailing list