[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclibc
Subject:    seg fault before main() in _pthread_cleanup_push_defer
From:       carmelo73 () gmail ! com (Carmelo Amoroso)
Date:       2008-07-21 7:07:37
Message-ID: 2ccd6e3c0807210007m5215bf4cqa45c5a84965cdf23 () mail ! gmail ! com
[Download RAW message or body]

On 17/07/2008, Karl Hiramoto <karl at hiramoto.org> wrote:
> Hi,
>
> Previously i was using gcc 3.4.6, uclibc 0.28.3, kernel 2.6.16  and my
> program worked.
>
> I upgraded to gcc 4.2.4, uclibc 0.29, kernel 2.6.26  (using the current
> buildroot trunk  and linuxthreads.old)
>
> And now i have:
>
> running gdb on the target:
>
>  gdb /usr/bin/myprog
> GNU gdb 6.6
> Copyright (C) 2006 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 "armeb-linux-uclibc"...
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) break main
> Breakpoint 1 at 0xc0e8: file /home/karl/Work/myprog.c, line 355.
> (gdb) run
> Starting program: /usr/bin/myprog
> [Thread debugging using libthread_db enabled]
> [New Thread 1024 (LWP 1321)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 1321)]
> 0x400beb70 in _pthread_cleanup_push_defer () from /lib/libc.so.0
>
>
> # /strace /usr/bin/myprog
> execve("/usr/bin/myprog", ["/usr/bin/myprog"], [/* 6 vars */]) = 0
> syscall: unknown syscall trap 0x00000017
>
>
>
> A lot of other software i have on the target works, but  I'm trying to
> debug what is going wrong with  this case of the segfault before main().
>
>
> Any ideas of things i can try?
> --
> Karl
>
Hi,
it seems you are accesing a null function pointer... this should be guarded
by checking for its not null value, but why it's not working is not clear.
This sounds to me something related to weak symbols issue, but only
with a deep analysis could be fuly understood.
May be something caused by usage of UCLIBC_MUTEX_LOCK macros.
Just an hint to continue with debugging.

Carmelo
>
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>

[prev in list] [next in list] [prev in thread] [next in thread]