Linux threads and insight 6.4 / 6.5

Linux threads and insight 6.4 / 6.5

[FALE(Leopold Faschalek)]

Hi,

I am running an arm linux system (2.6.15) with
a gdbserver and the insight debugger on an ubuntu
x86 linux.

The testprogram starts two threads and waits for
their completion.

If I have a breakpoint in the thread function the
gdbserver reports a SIGKILL and ends debugging after
'continuing'

The thread model is linuxthreads (not NPTL).

================== target ======================
/img # ./gdbserver64 192.168.184.10:5000 ./test                                 
Process ./test created; pid = 370                                               
Listening on port 5000                                                          
Remote debugging from host 192.168.184.10                                       
                                                                                
Child terminated with signal = 9                                                
                                                                                
Child terminated with signal = 0x9                                              
GDBserver exiting                                                               
/img # 
================= debug console =================
Breakpoint 3, main () at test.c:10

Program terminated with signal SIGKILL, Killed.
The program no longer exists.

Any ideas ?

Leopold Faschalek
-------------------------
Research & Development / Senior Software Developer

SKIDATA AG
Untersbergstraße 40
A-5083 Gartenau
[P] +43(0)6246/888-0
[F] +43(0)6246/888-7
[e] Leo.Faschalek@skidata.com
[w] www.skidata.com

Re: Linux threads and insight 6.4 / 6.5

[Steven J. Hill]

FALE(Leopold Faschalek) wrote:
> 
> The thread model is linuxthreads (not NPTL).
> 
> ================== target ======================
> /img # ./gdbserver64 192.168.184.10:5000 ./test                                 
> Process ./test created; pid = 370                                               
> Listening on port 5000                                                          
> Remote debugging from host 192.168.184.10                                       
>                                                                                 
> Child terminated with signal = 9                                                
>                                                                                 
> Child terminated with signal = 0x9                                              
> GDBserver exiting                                                               
> 
That's okay. I'm using NPTL on MIPS with the latest gdbserver (6.5) and
it does the exact same thing for me, kind of. Mine exits with signal 5.
As usual, threads support is iffy.

-Steve

Re: Linux threads and insight 6.4 / 6.5

[Daniel Jacobowitz]

On Tue, Jun 27, 2006 at 07:26:45PM -0500, Steven J. Hill wrote:
> FALE(Leopold Faschalek) wrote:
> > 
> > The thread model is linuxthreads (not NPTL).
> > 
> > ================== target ======================
> > /img # ./gdbserver64 192.168.184.10:5000 ./test                                 
> > Process ./test created; pid = 370                                               
> > Listening on port 5000                                                          
> > Remote debugging from host 192.168.184.10                                       
> >                                                                                 
> > Child terminated with signal = 9                                                
> >                                                                                 
> > Child terminated with signal = 0x9                                              
> > GDBserver exiting                                                               

Sorry, I didn't respond to this because I don't know what could cause
it.  You might want to search the archives for problems with thread
debugging; the usual suspects are library mismatches.

> That's okay. I'm using NPTL on MIPS with the latest gdbserver (6.5) and
> it does the exact same thing for me, kind of. Mine exits with signal 5.
> As usual, threads support is iffy.

With signal 5 is a clear signal that gdbserver has not enabled thread
support, either because of a mismatch or a problem with libthread_db
support on your target.  When one thread hits a breakpoint, if another
thread is running outside of debugger control, the kernel may terminate
the entire process.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Linux threads and insight 6.4 / 6.5

[Steven J. Hill]

Daniel Jacobowitz wrote:
> 
> With signal 5 is a clear signal that gdbserver has not enabled thread
> support, either because of a mismatch or a problem with libthread_db
> support on your target.  When one thread hits a breakpoint, if another
> thread is running outside of debugger control, the kernel may terminate
> the entire process.
> 
Using glibc NPTL with both gdb and gdbserver compiled from the same 6.4
source and gdbserver built against the exact same NPTL libraries I get:

   Cannot find new threads: capability not available

with an eventual termination of the process. So what mismatch or problem
with libthread_db should I be looking for? Thanks.

-Steve

Re: Linux threads and insight 6.4 / 6.5

[Daniel Jacobowitz]

On Tue, Jun 27, 2006 at 08:05:22PM -0500, Steven J. Hill wrote:
> Daniel Jacobowitz wrote:
> > 
> > With signal 5 is a clear signal that gdbserver has not enabled thread
> > support, either because of a mismatch or a problem with libthread_db
> > support on your target.  When one thread hits a breakpoint, if another
> > thread is running outside of debugger control, the kernel may terminate
> > the entire process.
> > 
> Using glibc NPTL with both gdb and gdbserver compiled from the same 6.4
> source and gdbserver built against the exact same NPTL libraries I get:
> 
>    Cannot find new threads: capability not available
> 
> with an eventual termination of the process. So what mismatch or problem
> with libthread_db should I be looking for? Thanks.

Try HEAD.  You didn't say what platform you were using, but guessing
MIPS, you need something newer.

-- 
Daniel Jacobowitz
CodeSourcery