Dag-Erling Smørgrav wrote: >Jason Andresen <jandrese_at_mitre.org> writes: > > >>It seems to me that every libpthread.so.1 maps to a libc_r.so.5, but >>when I actually run pan it still crashes and shows libpthread in the >>backtrace. Does anybody have a clue as to what is going on here? >> >> > >gdb doesn't know about libmap.conf, so the backtrace is wrong. > >DES > > My understanding is that the dynamic linker fills a link_map (see sys/link_elf.h) structure with the mapped name, and gdb grovels for this in the core: it should work correctly on a corefile. Sounds more like libpthread and libc_r are both in-process to me. Jason, try "i sh" from gdb to see what libraries were loaded in the process when it dumped. Interestingly, from the stack trace, frame 3 shows "re_search" calling into the main application, not a shared library, at the "??" bit (the instruction pointer is in the wrong range for a shared library): It sounds like the application is implementing a function that should probably be resolved from a shared library, and the linker is binding the application version instead of the standard one: that might be an issue. (I don't think the regex library ever uses callbacks, which would be the only other reason I can think it'd happen) The sysutils/pstack has a good chance of finding the name of the "??" function if you want to run that on the corefile: it takes the dynamic exported functions into account as well as the debug information when finding function names. HTH, Peter.Received on Thu Mar 18 2004 - 06:01:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:48 UTC