This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb runs multi-threaded with non-threaded app and gets SEGV
- From: Larry Martell <larry at software-horizons dot com>
- To: ramana dot radhakrishnan at codito dot com
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 15 Jul 2005 14:02:58 -0700 (PDT)
- Subject: Re: gdb runs multi-threaded with non-threaded app and gets SEGV
- Reply-to: larry at software-horizons dot com
--- Ramana Radhakrishnan
<ramana.radhakrishnan@codito.com> wrote:
> On Fri, 2005-07-15 at 11:25 -0700, Larry Martell
> wrote:
> > I have a program that has 1 line of code - a call
> to
> > a third party libary function:
> >
> > #include "ni488.h"
> >
> > int main() {
> > int handle = ibdev(0, 7, 0, 10, 1, 0);
> > }
>
>
> That is not enough info for us to help you with .
> Try CVS head or a more
> recent version of gdb and see if that works.
OK, I've upgraded to gdb 6.3
> Whats the version of libc ,
2.3.3
> gcc
3.4.1
> Also maybe your 3rd party
> library might be multithreaded for all we know. Do a
> ldd on the library if its a .so and check .
OK, an ldd showed:
libpthread.so.0 => /lib/tls/libpthread.so.0
(0x40278000)
So apparently the 3rd party lib is multithreaded.
So that answers 1 question. But the more important one
is why I get the SEGV in gdb, but not when I run the
program without gdb?
Here's the deal - I am developing an app (that is
not getting a SEGV) and I wanted to debug it. When
I ran the app in gdb it got the SEGV on my call to
ibdev. Thinking I probably had a memory corruption
somewhere in my application I ran valgrind on it.
It said the 3rd party lib was attempting to jump
to address 0. Still thinking it was my issue, I
created the single line test program (shown at the
top of this message). And that's where I am now - I
need gdb to get past this call so I can debug my
actaul app.
Thanks!
-larry
> > The program is not multi-threaded nor does not
> link
> > with any multi-threaded libs. It's built like
> this:
> >
> > gcc -g -o nitest nitest.c -lgpibapi
> >
> > If I run the program outside of the debugger it
> does
> > not crash.
> >
> > If I run it from within gdb here's what I get:
> >
> > $ gdb nitest
> > GNU gdb 6.2-2mdk (Mandrakelinux)
> > Copyright 2004 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
> > "i586-mandrake-linux-gnu"...Using host
> libthread_db
> > library "/lib/tls/libthread_db.so.1".
> >
> > (gdb) start
> > Breakpoint 1 at 0x8048398: file nitest.c, line 4.
> > Starting program: /home/martell/src/nitest2/nitest
> > [Thread debugging using libthread_db enabled]
> > [New Thread 1076484320 (LWP 9873)]
> > [Switching to Thread 1076484320 (LWP 9873)]
> > main () at nitest.c:4
> > 4 int handle = ibdev(0, 7, 0, 10, 1,
> 0);
> > (gdb) c
> > Continuing.
> > [New Thread 1085078448 (LWP 9876)]
> > [New Thread 1093471152 (LWP 9877)]
> >
> > Program received signal SIGSEGV, Segmentation
> fault.
> > [Switching to Thread 1085078448 (LWP 9876)]
> > 0x4005d609 in ?? () from
> > /usr/local/lib/libgpibapi.so.2
> >
> > Can anyone tell me why gdb runs this as
> multi-threaded
> > and why I get a SEGV in gdb, but I do not when I
> run
> > it outside of gdb?
> >
> > Thanks!
> > -larry
>
>
>