Bug 173915 - Can't attach to process with "hand-made" threads
Summary: Can't attach to process with "hand-made" threads
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gdb
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jan Kratochvil
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks: 200951
TreeView+ depends on / blocked
 
Reported: 2005-11-22 16:28 UTC by Bastien Nocera
Modified: 2015-01-08 00:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-02-24 17:41:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bastien Nocera 2005-11-22 16:28:00 UTC
gdb-6.3.0.0-1.59

When attaching to a process using an old version of the Quadrics library, gdb
fails to attach to some "threads":
[...]
Reading symbols from /lib/tls/libpthread.so.0...Reading symbols from
/usr/lib/debug/lib/tls/libpthread-2.3.4.so.debug...done.
[Thread debugging using libthread_db enabled]
[New Thread 1076535136 (LWP -1)]
Error while reading shared library symbols:
Can't attach LWP -1: No such process
[...]

Quadrics creates its "threads" using:
        if ((res = __clone (elan3_lwp, stack + ELANLWP_STACK_SIZE,
                            CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND,
                            (void *) ctx)) == -1)
        {
            elan3_syscall_detach(ctx);
            return(res);
        }

Whereas the glibc creates a thread using:

  int clone_flags = (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGNAL
             | CLONE_SETTLS | CLONE_PARENT_SETTID
             | CLONE_CHILD_CLEARTID | CLONE_SYSVSEM
#if __ASSUME_NO_CLONE_DETACHED == 0
             | CLONE_DETACHED
#endif
             | 0);

Comment 1 Jan Kratochvil 2006-07-29 23:44:17 UTC
Your installed "libthread_db.so.1" just needs to be compatible with the thread
implementation in the specific application.
Please provide the specific version of the Quadrics (libmpi?) binary library, if
still relevant.  Also RHEL4 provides both linuxthreads (now deprecated) and NPTL
threads implementation and it needs to match properly.
In fact more important are the specific memory structures created for the
threads ("struct pthread").  In each case you could provide your own old-MPI(?)
compatible "libthread_db.so.1" implementation, still I am not sure if it is
worth the effort.


Comment 2 Andrew Cagney 2006-07-31 16:03:27 UTC
RHEL 4.4 contains a technology preview of frysk (http://sourceware.org/frysk),
it would be useful to know if frysk can at least attach to such processes.


Comment 4 Jay Turner 2006-08-01 17:57:29 UTC
QE ack.  Bastian, hopefully you can help us out with testing or provide a testcase?

Comment 7 RHEL Program Management 2006-08-18 16:58:39 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 10 RHEL Program Management 2007-02-24 17:41:18 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 


Note You need to log in before you can comment on or make changes to this bug.