gdb runs multi-threaded with non-threaded app and gets SEGV

gdb runs multi-threaded with non-threaded app and gets SEGV

[Larry Martell]

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);
}


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

Re: gdb runs multi-threaded with non-threaded app and gets SEGV

[Ramana Radhakrishnan]

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. Whats the version of libc ,
gcc that you are building your app with ? 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 .

cheers
Ramana


> 
> 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

Re: gdb runs multi-threaded with non-threaded app and gets SEGV

[Larry Martell]

--- 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
> 
> 
> 

Re: gdb runs multi-threaded with non-threaded app and gets SEGV

[Min Xu (Hsu)]

Larry,

How about you run the program and let the program pass the
lib call without using GDB. And spin there until gdb is attached?

-Min

On Fri, 15 Jul 2005 Larry Martell wrote :
> --- 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
> > 
> > 
> > 
> 

Re: gdb runs multi-threaded with non-threaded app and gets SEGV

[Larry Martell]

--- "Min Xu (Hsu)" <xu@cs.wisc.edu> wrote:

> Larry,
> 
> How about you run the program and let the program
> pass the
> lib call without using GDB. And spin there until gdb
> is attached?

I tried this, but after it attaches to the process,
as then I try to continue it, it immediatly gets
a SEGV. And it sounded like such a good idea too :-(

Thanks!
-larry

> On Fri, 15 Jul 2005 Larry Martell wrote :
> > --- 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
> > >
> > >
> > >
> >
> 
> 

Re: gdb runs multi-threaded with non-threaded app and gets SEGV

[Min Xu (Hsu)]

On Fri, 15 Jul 2005 Larry Martell wrote :
> --- "Min Xu (Hsu)" <xu@cs.wisc.edu> wrote:
> 
> > Larry,
> > 
> > How about you run the program and let the program
> > pass the
> > lib call without using GDB. And spin there until gdb
> > is attached?
> 
> I tried this, but after it attaches to the process,
> as then I try to continue it, it immediatly gets
> a SEGV. And it sounded like such a good idea too :-(

How can this be possible is beyond me. :-(

Are you using SPARC? One thing may or may not have something to do
with this is "non-faulting loads" in SPARC. Maybe, without
gdb, your program didn't SEGV since it was using
"non-faulting loads"?

Re: gdb runs multi-threaded with non-threaded app and gets SEGV

[Larry Martell]

--- "Min Xu (Hsu)" <xu@cs.wisc.edu> wrote:
> On Fri, 15 Jul 2005 Larry Martell wrote :
> > --- "Min Xu (Hsu)" <xu@cs.wisc.edu> wrote:
> >
> > > Larry,
> > >
> > > How about you run the program and let the
> program
> > > pass the
> > > lib call without using GDB. And spin there until
> gdb
> > > is attached?
> >
> > I tried this, but after it attaches to the
> process,
> > as then I try to continue it, it immediatly gets
> > a SEGV. And it sounded like such a good idea too
> :-(
> 
> How can this be possible is beyond me. :-(
> 
> Are you using SPARC? 

No, I'm on a P4 running Linux. My app makes many calls
to functions from this lib. It seems a call to any
one of them causes the SEGV from within gdb. Like I
said before, it doesn't do this when I run it outside
of gdb, but it worries me. (I had forgotten how much
fun it is debugging with printf's ;-)

-larry

Re: gdb runs multi-threaded with non-threaded app and gets SEGV

[Larry Martell]

--- Larry Martell <larry@software-horizons.com> wrote:
> --- "Min Xu (Hsu)" <xu@cs.wisc.edu> wrote:
> > On Fri, 15 Jul 2005 Larry Martell wrote :
> > > --- "Min Xu (Hsu)" <xu@cs.wisc.edu> wrote:
> > >
> > > > Larry,
> > > >
> > > > How about you run the program and let the
> > program
> > > > pass the
> > > > lib call without using GDB. And spin there
> until
> > gdb
> > > > is attached?
> > >
> > > I tried this, but after it attaches to the
> > process,
> > > as then I try to continue it, it immediatly gets
> > > a SEGV. And it sounded like such a good idea too
> > :-(
> >
> > How can this be possible is beyond me. :-(
> >
> > Are yo using SPARC?
> 
> No, I'm on a P4 running Linux. My app makes many
> calls
> to functions from this lib. It seems a call to any
> one of them causes the SEGV from within gdb. Like I
> said before, it doesn't do this when I run it
> outside
> of gdb, but it worries me. (I had forgotten how much
> fun it is debugging with printf's ;-)

I just got an email from the third party lib
vendor (National Instruments):

> We have found incompatibilities with GDB, valgrind,
> and the NI-488.2 driver.  This will be fixed in the
> next version of our driver.

So I guess I'm sol wrt gdb until they fix this lib :-(

Thanks to all who here who replied and tried to help.

-larry