0004690: "Can't read pathname for load map"

Notes
(0008797) pfelecan (manager) 2011-02-16 10:00	The reason for which the Debian maintainer gives that advice is that the failure of the user program happens in the libc6 and for having an "usable" stack trace for that portion of code he needs the debugging symbols of the library itself. If you give me a simple example which I can reproduce I can look into it.

(0008798) phil (reporter) 2011-02-16 18:24	oh! hmm. it sounds like you are saying, "gdb is just saying, 'cant load debugging symbols'" but, older versions said pretty much just that, and no more. It's .. odd.. to see the newer version complain about I/O errors. Hmm. and in fact, using a more trivial example, where I merely used "strip" on a program, it does just that: Reading symbols from [testfile]...(no debugging symbols found)...done. Hmmm.. experimenting a little more... when I try to just [gdb badprog], it merely complains that way. However, when I specifically try to load it up with the corefile I'm interested in.. that's when it goes all ga-ga. I should mention that this was an auto-generated coredump, by means of: $ coreadm global core file pattern: /var/crash/core.%f.%p Additionally... loading in the thing with dbx instead of gdb, gives a functional stack trace. I unfortunately do not know for sure which version of cc it was compiled with. but the working dbx I tried, is from sun compiler 12.0

(0008799) pfelecan (manager) 2011-02-16 19:30	It doesn't says exactly that. It says that for the code which is the probable cause of the core it has no symbols. It's not unusual that a program fails in the startup code, even before main(). gdb itself was compiled with gcc, release 4. Again, if you provide me an example of code which exercises the behavior that you describe I will look into it. Otherwise all that I can say is that "it works for me".

(0008800) phil (reporter) 2011-02-16 19:59	Unfortunately, I cant share the particular example with you. But have you tried debugging from core dumps? If you compile the code below with cc (no -g), then dbx correctly says crash occurred in main() gdb is just completely lost, however. Actually, even if you compile with gcc, the same is true. so perhaps core dump analysis is broken. -------------------- #include <stdio.h> int main(){ char *crashit; write(1,"This is a test\n",16); crashit=NULL; write(1,crashit,16); printf("a stringie %s ... \n",NULL); write(1,"This is A TEST\n",16); }

(0008801) pfelecan (manager) 2011-02-16 21:41	There is an issue with the 64 bit gdb... I'll investigate in depth in the next days and hope to provide a solution, In the mean time there is the 32 bit version of gdb which works. Use: /opt/csw/bin/sparcv8/gdb or /opt/csw/bin/i486/gdb (on Solaris 9 the gdb in 32 bit on Intel architecture)

(0010054) pfelecan (manager) 2012-07-25 08:58	The freshly released package containing version 7.4.1 should correct this. Anyway, feedback is welcome and if the issue persists it can be re-opened.

Relationships

OpenCSW Bug Tracker