Notes |
(0005174)
carmelo73
02-20-08 04:40
|
From your output there is no evidence of a segfault. Please provide more information.
Command line used to build your application. Source code if available.
Further I suggest you to build with debug synmbol (both your application and uclibc) and start using gdb to debug.
The info you provide are not enough to figure out what is going wrong |
| |
(0005224)
kannappan
02-22-08 00:06
|
The problem happens when -lpthread is used along with -lc.
for example:
# arm-linux-gcc -lc -lpthread sample.c
The strace for this attached.
The same program works when i compile with
# arm-linux-gcc -lpthread sample.c |
| |
(0005234)
carmelo73
02-22-08 00:13
|
As a general suggestion, you don't need to link explicitly against libc (-lc)...
it is done by default by the compiler (append -v at your build command and you will see what it is doing silently)
Further are you sure arm-linux-gcc is properly configured for uClibc ?
Could you post the output of the command readelf -l <executable> ? |
| |
(0005254)
vapier
02-22-08 17:25
|
straces are not terribly useful when talking about a threading crash
please post a source code test case which we can compile/debug |
| |
(0005494)
kannappan
02-28-08 02:32
|
Following is the output of readelf
[kans@localhost test]$ arm-linux-readelf -l a.out
Elf file type is EXEC (Executable file)
Entry point 0x83ac
There are 5 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x00008034 0x00008034 0x000a0 0x000a0 R E 0x4
INTERP 0x0000d4 0x000080d4 0x000080d4 0x00014 0x00014 R 0x1
[Requesting program interpreter: /lib/ld-uClibc.so.0]
LOAD 0x000000 0x00008000 0x00008000 0x0050c 0x0050c R E 0x8000
LOAD 0x00050c 0x0001050c 0x0001050c 0x000ec 0x00108 RW 0x8000
DYNAMIC 0x000518 0x00010518 0x00010518 0x000c0 0x000c0 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .hash .dynsym .dynstr .rel.plt .init .plt .text .fini .rodata .eh_frame
03 .init_array .fini_array .jcr .dynamic .got .data .bss
04 .dynamic
Following are the output when compiled with -v option
Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with: /data/buildroot/buildroot/toolchain_build_arm/gcc-4.1.2/configure --prefix=/data/buildroot/buildroot/build_arm/staging_dir --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibcgnueabi --enable-languages=c,c++ --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --disable-nls --enable-threads --disable-multilib --with-float=soft
Thread model: posix
gcc version 4.1.2
/data/buildroot/buildroot/build_arm/staging_dir/libexec/gcc/arm-linux-uclibcgnueabi/4.1.2/cc1 -quiet -v sample.c -quiet -dumpbase sample.c -mfloat-abi=soft -auxbase sample -version -o /tmp/ccESRQ7x.s
ignoring nonexistent directory "/data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/../../../../arm-linux-uclibcgnueabi/include"
#include "..." search starts here:
#include <...> search starts here:
/data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/include
/data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/../../../../arm-linux-uclibcgnueabi/sys-include
End of search list.
GNU C version 4.1.2 (arm-linux-uclibcgnueabi)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-8).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64298
Compiler executable checksum: 38e7075577afcde72725d9029281c4bb
/data/buildroot/buildroot/build_arm/staging_dir/usr/bin/arm-linux-uclibcgnueabi-as -mfloat-abi=soft -meabi=4 -o /tmp/ccW0JqfY.o /tmp/ccESRQ7x.s
/data/buildroot/buildroot/build_arm/staging_dir/libexec/gcc/arm-linux-uclibcgnueabi/4.1.2/collect2 --eh-frame-hdr -dynamic-linker /lib/ld-uClibc.so.0 -X -m armelf_linux_eabi /data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/../../../../arm-linux-uclibcgnueabi/lib/crt1.o /data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/../../../../arm-linux-uclibcgnueabi/lib/crti.o /data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/crtbegin.o -L/data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2 -L/data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/../../../../arm-linux-uclibcgnueabi/lib /tmp/ccW0JqfY.o -lpthread -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/crtend.o /data/buildroot/buildroot/build_arm/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.2/../../../../arm-linux-uclibcgnueabi/lib/crtn.o |
| |
(0006074)
xi
03-26-08 14:48
edited on: 03-26-08 14:55
|
This is very similar to what I encountered with our MIPS toolchain and NPTL. 0002414 might be the same problem too.
I found one potential cause:
- Once libpthread is linked, standard loader is used instead of uClibc loader
Here is a console log showing this problem with ldd:
$ /opt/toolchains/uclibc-crosstools-gcc-4.2.1-7/usr/bin/mips-linux-uclibc-gcc -o test testc.o
/opt/toolchains/uclibc-crosstools-gcc-4.2.1-7/usr/bin/mips-linux-uclibc-ldd test
checking sub-depends for 'not found'
libc.so.0 => not found (0x00000000)
/lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)
/opt/toolchains/uclibc-crosstools-gcc-4.2.1-7/usr/bin/mips-linux-uclibc-gcc -o test testc.o –lpthread
$ /opt/toolchains/uclibc-crosstools-gcc-4.2.1-7/usr/bin/mips-linux-uclibc-ldd test
checking sub-depends for '/lib/libpthread.so.0'
checking sub-depends for 'not found'
checking sub-depends for '/lib/libc.so.6'
libpthread.so.0 => /lib/libpthread.so.0 (0x00000000)
libc.so.0 => not found (0x00000000)
libc.so.6 => /lib/libc.so.6 (0x00000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
$
|
| |
(0006314)
bla
04-02-08 01:38
|
I have the same issue on arm (nommu), uclibc 0.9.29. Using gdb on the target I have tracked the problem down to the call to __pthread_initialize_minimal during init. The call takes place via some memory lookup, but ends up in the wrong place (somewhere in the data segment). If I look at the target code with objdump -x I see this disturbing fact:
00000000 w *UND* 00000000 __pthread_initialize_minimal
So it's no wonder the call goes wrong, because the function code is not included. It seems to me that something in the link process must have gone wrong. The linker has clearly filled out the memory locations used in the call with something, but forgot to include the actual code.
This is the part of the code where I see the failure (objdump -d):
00000898 <__GI___uClibc_init>:
898: e92d4010 stmdb sp!, {r4, lr}
89c: e59f4054 ldr r4, [pc, 0000084] ; 8f8 <__GI___uClibc_init+0x60>
8a0: e59f0054 ldr r0, [pc, 0000084] ; 8fc <__GI___uClibc_init+0x64>
8a4: e08f4004 add r4, pc, r4
8a8: e7943000 ldr r3, [r4, r0]
8ac: e3530000 cmp r3, 0 ; 0x0
8b0: 18bd8010 ldmneia sp!, {r4, pc}
8b4: e59f3044 ldr r3, [pc, 0000068] ; 900 <__GI___uClibc_init+0x68>
8b8: e7941003 ldr r1, [r4, r3]
8bc: e59f3040 ldr r3, [pc, 0000064] ; 904 <__GI___uClibc_init+0x6c>
8c0: e7942003 ldr r2, [r4, r3]
8c4: e3a03001 mov r3, 0000001 ; 0x1
8c8: e7843000 str r3, [r4, r0]
8cc: e3510000 cmp r1, 0 ; 0x0
8d0: e3a03a01 mov r3, 4096 ; 0x1000
8d4: e5823000 str r3, [r2]
8d8: 11a0e00f movne lr, pc
8dc: 11a0f001 movne pc, r1 <---------- FAILS HERE!!!
8e0: e59f3020 ldr r3, [pc, 0000032] ; 908 <__GI___uClibc_init+0x70>
8e4: e0843003 add r3, r4, r3
8e8: e3530000 cmp r3, 0 ; 0x0
8ec: 08bd8010 ldmeqia sp!, {r4, pc}
8f0: e8bd4010 ldmia sp!, {r4, lr}
8f4: eafffe30 b fffffa84 <_ebss+0xffffbaf4>
8f8: 00001414 andeq r1, r0, r4, lsl r4
8fc: 000022b8 streqh r2, [r0], -r8
900: 0000002c andeq r0, r0, ip, lsr 0000032
904: 00000044 andeq r0, r0, r4, asr 0000032
908: ffffe4fc undefined instruction 0xffffe4fc |
| |
(0006374)
hank_le
04-03-08 09:51
edited on: 04-03-08 10:09
|
I am having a similar problem for an i586 target using uClibc-0.9.29, binutils 2.18, and gcc 4.2.1.
I cross compile with the following :
export PATH_TO_BUILDROOT=/home/leinhos/src/buildroot
export CC=$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/bin/i586-linux-gcc
export LD=$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/bin/i586-linux-ld
export CPPFLAGS=-I$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/include
export LDFLAGS=-L$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/lib
export PATH=$PATH:$PATH_TO_BUILDROOT/build_i586/staging_dir/usr/bin
and use the following makefile target line:
CFLAGS += -g -Wall
LIBS = -lpthread
OBJS = ${SRCS:.c=.o}
vc_bridge: ${OBJS}
${CC} ${LIBS} -o $@ ${OBJS}
If I check the backtrace on the target, I see:
(gdb) set solib-absolute-prefix /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/
(gdb) file vc_bridge
Reading symbols from /home/leinhos/src/vc_bridge-cvs/vc_bridge...done.
(gdb) target remote 192.168.9.200:1111
Remote debugging using 192.168.9.200:1111
warning: Remote failure reply: E01
0xb7f758b0 in _start () from /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/ld-uClibc.so.0
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xb7efc0a2 in memcpy () from /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/libc.so.0
(gdb) bt
0 0xb7efc0a2 in memcpy () from /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/libc.so.0
0000001 0xb7f13ddc in __libc_pthread_init ()
from /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/libc.so.0
2 0xb7f647f8 in __pthread_initialize_minimal ()
from /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/libpthread.so.0
0000003 0xb7f13ed9 in __uClibc_init () from /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/libc.so.0
0000004 0xb7f78393 in _dl_get_ready_to_run ()
from /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/ld-uClibc.so.0
0000005 0xb7f786a0 in ?? () from /home/leinhos/src/buildroot/project_build_i586/nuwcmp/root/lib/ld-uClibc.so.0
0000006 0xbf94a590 in ?? ()
0000007 0xb7f75000 in ?? ()
0000008 0xbf94a674 in ?? ()
0000009 0xbf94a70c in ?? ()
0000010 0xbf94a704 in ?? ()
0000011 0xbf94a674 in ?? ()
0000012 0xb7f75000 in ?? ()
0000013 0x00000002 in ?? ()
0000014 0x00000000 in ?? ()
I don't have any problems with applications compiled without pthreads.
compiling with the -v flag gives:
make
/home/leinhos/src/buildroot/build_i586/staging_dir/usr/bin/i586-linux-gcc -v -g -Wall -I/home/leinhos/src/buildroot/build_i586/staging_dir/usr/include -c -o vc_bridge.o vc_bridge.c
Using built-in specs.
Target: i586-linux-uclibc
Configured with: /home/leinhos/src/buildroot/toolchain_build_i586/gcc-4.2.1/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=i586-linux-uclibc --enable-languages=c,c++ --with-sysroot=/home/leinhos/src/buildroot/build_i586/staging_dir --with-build-time-tools=/home/leinhos/src/buildroot/build_i586/staging_dir/usr/i586-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/leinhos/src/buildroot/toolchain_build_i586/gmp --with-mpfr=/home/leinhos/src/buildroot/toolchain_build_i586/mpfr --enable-threads --disable-multilib --with-arch=i586 --with-tune=i586
Thread model: posix
gcc version 4.2.1
/home/leinhos/src/buildroot/build_i586/staging_dir/usr/bin/../libexec/gcc/i586-linux-uclibc/4.2.1/cc1 -quiet -v -I/home/leinhos/src/buildroot/build_i586/staging_dir/usr/include -iprefix /home/leinhos/src/buildroot/build_i586/staging_dir/usr/bin/../lib/gcc/i586-linux-uclibc/4.2.1/ vc_bridge.c -quiet -dumpbase vc_bridge.c -mtune=i586 -march=i586 -auxbase-strip vc_bridge.o -g -Wall -version -o /tmp/ccbRnIWd.s
ignoring nonexistent directory "/home/leinhos/src/buildroot/build_i586/staging_dir/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/i586-linux-uclibc/4.2.1/include"
ignoring nonexistent directory "/usr/lib/gcc/../../i586-linux-uclibc/include"
ignoring duplicate directory "/home/leinhos/src/buildroot/build_i586/staging_dir/usr/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
/home/leinhos/src/buildroot/build_i586/staging_dir/usr/bin/../lib/gcc/i586-linux-uclibc/4.2.1/include
/home/leinhos/src/buildroot/build_i586/staging_dir/usr/bin/../lib/gcc/i586-linux-uclibc/4.2.1/../../../../i586-linux-uclibc/include
/home/leinhos/src/buildroot/build_i586/staging_dir/usr/include
End of search list.
GNU C version 4.2.1 (i586-linux-uclibc)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-9).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6e55b40c6d41227a038ca2fc35b4a5f0
/home/leinhos/src/buildroot/build_i586/staging_dir/usr/bin/../lib/gcc/i586-linux-uclibc/4.2.1/../../../../i586-linux-uclibc/bin/as -V -Qy -o vc_bridge.o /tmp/ccbRnIWd.s
GNU assembler version 2.18 (i586-linux-uclibc) using BFD version (GNU Binutils) 2.18
/home/leinhos/src/buildroot/build_i586/staging_dir/usr/bin/i586-linux-gcc -lpthread -o vc_bridge endian.o cadcac.o pencilbeam.o vcData.o vcdata_thread.o ds.o remus_parse.o mp_thread.o remus_thread.o cadcac_thread.o pb_thread.o vc_bridge.o
|
| |
(0006424)
khem
04-06-08 23:30
|
Do you see the same problem with both linuxthreads as well as linuxthreads.old ? |
| |
(0006444)
hank_le
04-07-08 13:02
edited on: 04-08-08 04:33
|
Yes and No. I have the same problem when using linuxthreads, but the problem goes away with linuxthreads.old
(using pthread_test.c from 0002834 -- sorry for the redundant bug post)
Oddly enough, pthread_test.c compiled for linuxthreads runs ok on the linuxthreads.old target, but not the reverse (the linuxthread.old application does not run on the linuxthread target).
|
| |
(0006704)
carmelo73
04-19-08 22:57
|
Hi,
about your latest note on linuxthread vs linuxthreads.old.
Basically, what makes difference is the library you use at runtime.
So, use linuxthreads.old.
If you will be able to identify the problem in linuxyhreads impl.
and have a patch, please send to the list. |
| |
a [^] (2,996 bytes) 02-22-08 00:03
