Bug 86039 - upgraded RH errata kernel to 2.4.18-26smp breaks gdb thread traces
Summary: upgraded RH errata kernel to 2.4.18-26smp breaks gdb thread traces
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdb (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Elena Zannoni
QA Contact: Jay Turner
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-12 21:36 UTC by Dave Johnson
Modified: 2015-01-08 00:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-03-21 03:20:48 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Dave Johnson 2003-03-12 21:36:05 UTC
Description of problem:
After upgrading from 2.4.18-5smp to 2.4.18-26smp, multithreaded apps can
no longer be gdb'ed.  when one does "info threads" it comes back with
nothing.

One of the developer that writes all their things multithreaded noticed
this has occured with other people under different circumstances (links listed 
in other information category below).  Nobody has a resolution or insight into 
fixing it other than trying different versions of glibc and/or gdb.  (We tried 
different versions of gdb, to little luck).  

Tried gdb with standard 7.3, the updated errata gdb for 7.3, as well as
the rawhide version, same deal.

Should it matter if the apps are compiled with gcc3.2?

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. gdb <multitreaded app>
2. info threads
3. get back nothing.
    
Actual results:
nothing

Expected results:
list of threads and ability to get individual thread stack traces.

Additional info:

http://groups.google.com/groups?q=gdb++%22info+threads%
22+nothing&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-8&scoring=d&selm=3ad2175d.584929906%
40news.cis.dfn.de&rnum=8

http://groups.google.com/groups?q=gdb++%22info+threads%
22+nothing&hl=en&lr=lang_en&ie=UTF-8&oe=UTF-
8&scoring=d&selm=5.1.0.14.2.20020404215757.02eeab48%40ssl.rd1.net&rnum=3

Comment 1 Elena Zannoni 2003-03-12 22:47:03 UTC
Probably a libthread_db mismatch with the kernel. Need the appropriate glibc.
Nothing to do with gdb. 



Comment 2 Dave Johnson 2003-03-13 19:31:59 UTC
You can close this.  Glibc version was fine, user should not specify /lib in 
LD_LIBRARY_PATH at all.  User can still specify other lib dirs, but just don't 
put /lib in.  This will "override" the system from "automatically" 
choosing /lib/i686/libc vs. /lib/libc.




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