Itanium and GDB on 2.6.x kernels with pthreads

Itanium and GDB on 2.6.x kernels with pthreads

[David Lecomber]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

Dear all,

Attached is a simple program, and simple script for GDB (current CVS,
and previous versions)

gcc -o pf -g pf.c -lm -lpthread

gdb ./pf < gdb.script

The script is a break main and then 'next' four times, followed by quit.

On a 2.4.21 Itanium system, it's quick and quits happily.

On a 2.6.5 Itanium, it hangs during the later nexts.  Does anyone have a
more recent Itanium they could try and see if this is a transient kernel
issue?  

Note, the Intel IDB debugger does not have a problem with this test
case.

GDB consumes CPU, and a 'strace' shows it to be doing repeatedly:

wait4(29113, 0x60000fffffffa730, 0, NULL) = -1 ECHILD (No child
processes)
wait4(29113, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], __WCLONE,
NULL) = 29113
ptrace(PTRACE_CONT, 29113, 0, SIG_0)    = 0
wait4(29113, 0x60000fffffffa730, 0, NULL) = -1 ECHILD (No child
processes)


Also, just generally, signal processing is goofed up -- and if I try to
attach to the running GDB I just see:

Loaded symbols for /lib/tls/libthread_db.so.1
<signal handler called>
(gdb) bt
#0  <signal handler called>
Cannot access memory at address 0x28
(gdb) The program is running.  Quit anyway (and detach it)? (y or n) y


Anyone seen this before?  If someone could verify this is ok on their
system, I'd appreciate it..

d.


-- 
David Lecomber <david@allinea.com>

[-- Attachment #2: pf.c --]
[-- Type: text/x-csrc, Size: 465 bytes --]

#include <pthread.h>
#include <math.h>
#include <stdio.h>

void f(char* s)
{
  int i;
  printf("Hello from : %s\n", s);
  fflush(stdout);
  for (i = 0 ; i < 100000000; i++)
    {
      float f = sqrt(i);
    }
  printf("Goodbye from : %s\n", s);
  fflush(stdout);
}

int main()
{
  pthread_t t1;
  pthread_t t2;

  pthread_create(&t1, NULL, (void*) &f, "One");
  pthread_create(&t2, NULL, (void*) &f, "Two");

  pthread_join(t1, NULL);
  pthread_join(t2, NULL);

}

[-- Attachment #3: gdb.script --]
[-- Type: text/plain, Size: 32 bytes --]

b main
run 
next
next
next
quit

Re: Itanium and GDB on 2.6.x kernels with pthreads

[Andreas Schwab]

David Lecomber <david@allinea.com> writes:

> Also, just generally, signal processing is goofed up -- and if I try to
> attach to the running GDB I just see:
>
> Loaded symbols for /lib/tls/libthread_db.so.1
> <signal handler called>
> (gdb) bt
> #0  <signal handler called>
> Cannot access memory at address 0x28
> (gdb) The program is running.  Quit anyway (and detach it)? (y or n) y
>
>
> Anyone seen this before?

Please try a recent snapshot from CVS, this should already be fixed.  Also
make sure your gdb has been built with libunwind support and libunwind is
installed.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Itanium and GDB on 2.6.x kernels with pthreads

[David Lecomber]

Hi Andreas,

Yes, this part of the bug works fine now with the CVS snapshot.

Thanks,
David


 On Thu, 2005-09-08 at 00:14 +0200, Andreas Schwab wrote:
> David Lecomber <david@allinea.com> writes:
> 
> > Also, just generally, signal processing is goofed up -- and if I try to
> > attach to the running GDB I just see:
> >
> > Loaded symbols for /lib/tls/libthread_db.so.1
> > <signal handler called>
> > (gdb) bt
> > #0  <signal handler called>
> > Cannot access memory at address 0x28
> > (gdb) The program is running.  Quit anyway (and detach it)? (y or n) y
> >
> >
> > Anyone seen this before?
> 
> Please try a recent snapshot from CVS, this should already be fixed.  Also
> make sure your gdb has been built with libunwind support and libunwind is
> installed.
> 
> Andreas.
> 
-- 
David Lecomber 
CTO Allinea Software
Tel: +44 1926 623231
Fax: +44 1926 623232

Re: Itanium and GDB on 2.6.x kernels with pthreads

[Daniel Jacobowitz]

On Wed, Sep 07, 2005 at 05:23:56PM +0100, David Lecomber wrote:
> Dear all,
> 
> Attached is a simple program, and simple script for GDB (current CVS,
> and previous versions)
> 
> gcc -o pf -g pf.c -lm -lpthread
> 
> gdb ./pf < gdb.script
> 
> The script is a break main and then 'next' four times, followed by quit.
> 
> On a 2.4.21 Itanium system, it's quick and quits happily.
> 
> On a 2.6.5 Itanium, it hangs during the later nexts.  Does anyone have a
> more recent Itanium they could try and see if this is a transient kernel
> issue?  

And on 2.4.27 (-dsa-itanium-smp, on one of Debian's machines,
merulo.debian.org) it hangs during the first next.  Thread debugging is
completely hosed.  That's using the installed GDB 6.3.

Using a GDB I've built from CVS I get the same result.

If I strace gdb, it segfaults at the run command.  It's not the same
problem you're seeing, because gdb is not consuming CPU.

CW:  waitpid 17370 received Trace/breakpoint trap (stopped)
CW:  waitpid 17370 received Trace/breakpoint trap (stopped)
CW:  waitpid 17370 received Illegal instruction (stopped)
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 17370)]
LLR: PTRACE_SINGLESTEP process 17370, 0 (resume event thread)
LLW: waitpid 17370 received Trace/breakpoint trap (stopped)
LLW: Candidate event Trace/breakpoint trap (stopped) in LWP 17370.
LLTA: PTRACE_PEEKUSER LWP 17370, 0, 0 (OK)
SEL: Select single-step LWP 17370
LLW: trap_ptid is process 17370.
LLR: PTRACE_CONT process 17370, 0 (resume event thread)
LLW: waitpid 17370 received Illegal instruction (stopped)
LLW: Candidate event Illegal instruction (stopped) in LWP 17370.
LLTA: PTRACE_PEEKUSER LWP 17370, 0, 0 (OK)
LLR: PTRACE_SINGLESTEP process 17370, 0 (resume event thread)

Those sigill's should not be there, should they?  Something is
seriously broken in ia64-land...  I get them even running
single-threaded, but they're ignored because they happen at
breakpoints.  But I'm not convinced that they don't indicate a real
problem somewhere.

And single-steps take me nowhere useful, and most local variables can't
be displayed.

Without knowing something useful about ia64, I don't think I can
usefully debug this, and there's no guarantee that it's even the same
problem you're seeing.  Sorry.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Itanium and GDB on 2.6.x kernels with pthreads

[Daniel Jacobowitz]

On Sat, Sep 10, 2005 at 11:29:15AM -0400, Daniel Jacobowitz wrote:
> Those sigill's should not be there, should they?  Something is
> seriously broken in ia64-land...  I get them even running
> single-threaded, but they're ignored because they happen at
> breakpoints.  But I'm not convinced that they don't indicate a real
> problem somewhere.

For the record, the SIGILLs seem to be caused by turning this:
   nop.b 0x0
   nop.b 0x0
   br.ret.sptk.many b0 ;;

to this:

   break.b 0xccccc
   nop.b 0x0
   br.ret.sptk.many b0 ;;

Seems like a reasonable breakpoint to me.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Itanium and GDB on 2.6.x kernels with pthreads

[David Lecomber]

Well, although threading may be hosed on Daniel's Itanium, I  am
actually getting far better behaviour now on my own case.   The 'hosed'
version was built on 2.4.x kernel, with glibc 2.2.x, -- but when I
changed the build-host to the 2.6.x machine with glib 2.3.x all bad
behaviour vanished.   My mistake?

Regards
David