From: Balarama Krishna <balaram@samsung.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com
Subject: Re: pthread_create, Program received signal ?, Unknown signal
Date: Tue, 02 Sep 2003 11:57:00 -0000 [thread overview]
Message-ID: <1062503415.1343.204.camel@Lotus> (raw)
In-Reply-To: <20030901162616.GB7465@nevyn.them.org>
> You seem to be using glibc 2.3.x. Am I right?
>
> If so, try CVS gdb instead. A change in the definition of SIGRTMIN
> causes this symptom.
>
I got the latest CVS and built the gdb and gdbserver. I am getting the
following problem which is similar to the following
http://sources.redhat.com/ml/gdb/2002-12/msg00055.html
THE PROBLEM DESCRIPTION
=======================
CASE 1
------
Following is the screen shot while the multi-threaded application is
built statically
$ arm-linux-gcc -g threads.c -o threads-static -lpthread --static
/%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%/
GNU gdb 5.3.90_2003-09-02-cvs
Copyright 2003 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 "--host=i686-pc-linux-gnu
--target=arm-linux".
(gdb) set solib-absolute-prefix /dev/null
(gdb) set solib-search-path /home/balaram/links_to_lib_dir/lib
(gdb) file threads-static
Reading symbols from threads-static...done.
(gdb) target remote 107.108.3.197:2020
107.108.3.197:2020: Connection refused.
(gdb) target remote 107.108.3.197:2020
Remote debugging using 107.108.3.197:2020
0x000080e0 in _start ()
(gdb) b 9
Breakpoint 1 at 0x81f8: file threads.c, line 9.
(gdb) b 16
Breakpoint 2 at 0x8240: file threads.c, line 16.
(gdb) b 25
Breakpoint 3 at 0x8294: file threads.c, line 25.
(gdb) cont
Continuing.
[New Thread 16384]
[Switching to Thread 16384]
Breakpoint 1, main () at threads.c:9
9 if ( pthread_create(&thread_id, NULL, call_back, NULL)
!= 0){
(gdb) n
[New Thread 16386]
[Switching to Thread 16386]
Breakpoint 3, call_back (arg=0x0) at threads.c:25
25 printf("Thread Loop count (%d) \n", count);
(gdb) n
[Switching to Thread 16384]
Breakpoint 2, main () at threads.c:16
16 printf("Main Thread Count (%d) \n", count);
(gdb) n
14 count++;
(gdb) n
[Switching to Thread 16386]
Breakpoint 3, call_back (arg=0x0) at threads.c:25
25 printf("Thread Loop count (%d) \n", count);
(gdb) n
[Switching to Thread 16384]
Breakpoint 2, main () at threads.c:16
16 printf("Main Thread Count (%d) \n", count);
(gdb) n
14 count++;
(gdb) n
[Switching to Thread 16386]
Breakpoint 3, call_back (arg=0x0) at threads.c:25
25 printf("Thread Loop count (%d) \n", count);
(gdb) n
[Switching to Thread 16384]
Breakpoint 2, main () at threads.c:16
16 printf("Main Thread Count (%d) \n", count);
(gdb) n
14 count++;
(gdb) n
[Switching to Thread 16386]
Breakpoint 3, call_back (arg=0x0) at threads.c:25
25 printf("Thread Loop count (%d) \n", count);
(gdb) q
The program is running. Exit anyway? (y or n) y
/%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%/
CASE 2
------
Following is the screen shot when the multi-threaded application is
built with shared libraries
$ arm-linux-gcc -g threads.c -o threads-shared -lpthread
/%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%/
GNU gdb 5.3.90_2003-09-02-cvs
Copyright 2003 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 "--host=i686-pc-linux-gnu
--target=arm-linux".
(gdb) set solib-absolute-prefix /dev/null
(gdb) set solib-search-path /home/balaram/links_to_lib_dir/lib
(gdb) file threads-shared
Reading symbols from threads-shared...done.
(gdb) target remote 107.108.3.197:2020
Remote debugging using 107.108.3.197:2020
0x40002560 in ?? ()
(gdb) b 9
Breakpoint 1 at 0x84d0: file threads.c, line 9.
(gdb) b 16
Breakpoint 2 at 0x8518: file threads.c, line 16.
(gdb) b 25
Breakpoint 3 at 0x856c: file threads.c, line 25.
(gdb) cont
Continuing.
Breakpoint 1, main () at threads.c:9
9 if ( pthread_create(&thread_id, NULL, call_back, NULL)
!= 0){
(gdb) n
Program received signal SIG32, Real-time event 32.
0x4005b3a4 in ?? ()
(gdb) c
Continuing.
Breakpoint 2, main () at threads.c:16
16 printf("Main Thread Count (%d) \n", count);
(gdb) c
Continuing.
Breakpoint 2, main () at threads.c:16
16 printf("Main Thread Count (%d) \n", count);
(gdb) c
Continuing.
Breakpoint 2, main () at threads.c:16
16 printf("Main Thread Count (%d) \n", count);
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x400b52b4 in ?? ()
(gdb)
/%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%/
Conclusions
===========
1. Application runs successfully on the target without debugging, in
both the cases
2. So, it seems there is a problem on the HOST side in loading the
shared libraries. I kept the shared libraries (not stripped) in
/home/balaram/links_to_lib_dir/lib and set the parameters,
solib-absolute-prefix and solib-search-path as shown above
Following is the screen shot of the shared libraries on the HOST Side,
even the same set of libraries are used on the Target.
/&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&/
-rwxr-xr-x 1 balaram balaram 1093314 Sep 2 15:50 ld-2.3.1.so
lrwxrwxrwx 1 balaram balaram 11 Sep 2 15:56 ld-linux.so.2 ->
ld-2.3.1.so
-rwxr-xr-x 1 balaram balaram 17257712 Sep 2 15:51 libc-2.3.1.so
-rwxr-xr-x 1 balaram balaram 97137 Sep 2 15:51
libcrypt-2.3.1.so
lrwxrwxrwx 1 balaram balaram 17 Sep 2 15:56 libcrypt.so.1 ->
libcrypt-2.3.1.so
lrwxrwxrwx 1 balaram balaram 13 Sep 2 15:56 libc.so.6 ->
libc-2.3.1.so
-rwxr-xr-x 1 balaram balaram 65798 Sep 2 15:51 libdl-2.3.1.so
lrwxrwxrwx 1 balaram balaram 14 Sep 2 15:56 libdl.so.2 ->
libdl-2.3.1.so
-rwxr-xr-x 1 balaram balaram 2152488 Sep 2 15:51 libm-2.3.1.so
lrwxrwxrwx 1 balaram balaram 13 Sep 2 15:57 libm.so.6 ->
libm-2.3.1.so
-rwxr-xr-x 1 balaram balaram 1269102 Sep 2 15:52 libnsl-2.3.1.so
lrwxrwxrwx 1 balaram balaram 15 Sep 2 15:58 libnsl.so.1 ->
libnsl-2.3.1.so
-rwxr-xr-x 1 balaram balaram 94819 Sep 2 15:52
libnss_dns-2.3.1.so
lrwxrwxrwx 1 balaram balaram 19 Sep 2 15:58 libnss_dns.so.2
-> libnss_dns-2.3.1.so
-rwxr-xr-x 1 balaram balaram 418842 Sep 2 15:52
libnss_files-2.3.1.so
lrwxrwxrwx 1 balaram balaram 21 Sep 2 15:59
libnss_files.so.2 -> libnss_files-2.3.1.so
-rwxr-xr-x 1 balaram balaram 1065737 Sep 2 15:52
libpthread-0.10.so
lrwxrwxrwx 1 balaram balaram 18 Sep 2 15:59 libpthread.so.0
-> libpthread-0.10.so
-rwxr-xr-x 1 balaram balaram 503941 Sep 2 15:52
libresolv-2.3.1.so
lrwxrwxrwx 1 balaram balaram 18 Sep 2 15:59 libresolv.so.2
-> libresolv-2.3.1.so
-rwxr-xr-x 1 balaram balaram 1093631 Sep 2 15:52
libthread_db-1.0.so
lrwxrwxrwx 1 balaram balaram 19 Sep 2 15:59 libthread_db.so
-> libthread_db-1.0.so
lrwxrwxrwx 1 balaram balaram 19 Sep 2 15:59
libthread_db.so.1 -> libthread_db-1.0.so
-rwxr-xr-x 1 balaram balaram 84505 Sep 2 15:53 libutil-2.3.1.so
lrwxrwxrwx 1 balaram balaram 16 Sep 2 16:00 libutil.so.1 ->
libutil-2.3.1.so
/&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&/
Still, Am I missing anything out here????
Thanks and Regards,
Balaram.
next prev parent reply other threads:[~2003-09-02 11:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-01 13:18 Balarama Krishna
2003-09-01 16:26 ` Daniel Jacobowitz
2003-09-02 5:19 ` Balarama Krishna
2003-09-02 11:57 ` Balarama Krishna [this message]
2003-09-02 12:27 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1062503415.1343.204.camel@Lotus \
--to=balaram@samsung.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox