Bug 327 - segfault with setrlimit/pthread.old on 0.9.30.1
Summary: segfault with setrlimit/pthread.old on 0.9.30.1
Status: RESOLVED WORKSFORME
Alias: None
Product: uClibc
Classification: Unclassified
Component: Threads (show other bugs)
Version: 0.9.30.1
Hardware: PC Linux
: P5 normal
Target Milestone: 0.9.32
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-09 10:37 UTC by Bertrand Jacquin
Modified: 2012-04-18 09:00 UTC (History)
1 user (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: i586-geode-linux-uclibc
Build: i586-geode-linux-uclibc


Attachments
uclibc-0.9.30.1-r1.config (5.59 KB, text/plain)
2009-05-09 10:38 UTC, Bertrand Jacquin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bertrand Jacquin 2009-05-09 10:37:35 UTC
Hi,

I'm using gentoo crossdev-wrappers build environnement to build my own system with gcc 3.4.6-r2, kernel 2.6.28-r1 and libc/libthread_old 0.9.30.1-r1. All almost compile fine and work good, but not software linked with libpthread and doing setrlimit like e2fsprogs with chattr :

# chattr
Segmentation fault

And I get the following line in dmesg :
[470178.800998] chattr[6143]: segfault at 1ffe61 ip 00000000f7f59bd0 sp 00000000ffdca3c4 error 4 in libpthread-0.9.30.1.so[f7f55000+b000]

strace give the following :

ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
getpid()                                = 7492
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=2040*1024, rlim_max=RLIM_INFINITY}) = 0
rt_sigaction(SIGRTMIN, {0xf7f31109, [], SA_RESTORER, 0xf7f4766b}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xf7f31185, [RTMIN], SA_RESTORER, 0xf7f4766b}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0xf7f3126f, [], SA_RESTORER, 0xf7f4766b}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---

and gdb :
This GDB was configured as "i586-geode-linux-uclibc"...
(gdb) run
Starting program: /bin/chattr
[Thread debugging using libthread_db enabled]
[New Thread 0x400 (LWP 7575)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x400 (LWP 7575)]
0xf7f07bd0 in _pthread_cleanup_push_defer () from /lib/libpthread.so.0
(gdb) bt
#0  0xf7f07bd0 in _pthread_cleanup_push_defer () from /lib/libpthread.so.0
(gdb) br
Breakpoint 1 at 0xf7f07bd0

When I compile uclibc with debug, all works fine. That's a bit perturbing.

First, I don't understand why gdb can't give me more debug information, even if I build with CFLAGS=-g and nostrip

Second, I don't understand why this is working when debug is activated. I can't run device with a 51MB libc which is slowing down almost everything.

chattr is just an exemple, but that's the same with other libpthread/setrlimit using software (lsattr, squid).

Actually it fail with >= 0.9.29 and >=0.9.30 and work good with 0.9.28*

You'll find attached the config
Comment 1 Bertrand Jacquin 2009-05-09 10:38:27 UTC
Created attachment 309 [details]
uclibc-0.9.30.1-r1.config
Comment 2 Mike Frysinger 2009-07-22 06:31:39 UTC
chattr is working fine for me with Gentoo and uClibc 0.9.30.1.  is that the simplest app you can get to crash ?  i'm hoping you can find some simple C code for us to look at ...
Comment 3 Bertrand Jacquin 2009-07-22 22:55:51 UTC
Hi mike

(In reply to comment #2)
> chattr is working fine for me with Gentoo and uClibc 0.9.30.1.  is that the
> simplest app you can get to crash ?  i'm hoping you can find some simple C code
> for us to look at ...

I used to use gcc 3.4.6, and all binaries linked with libpthread segv before main like reported. I recompiled all the toolchain and embedded target with gcc 4.3 and it since to be finest. I still have others issues, but I need to investage better, will be done on holiday return.

Thanks for your reply.
Beber

Comment 4 Bernhard Reutner-Fischer 2010-03-03 20:21:53 UTC
Please provide a small, self-contained testcase.
Comment 5 Natanael Copa 2010-05-19 06:32:52 UTC
I bet this is fixed with nptl.
Comment 6 Bernhard Reutner-Fischer 2012-04-18 09:00:54 UTC
This is supposedly fixed by using NPTL so closing.