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
Probably a libthread_db mismatch with the kernel. Need the appropriate glibc. Nothing to do with gdb.
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.