topic Re: gdb problem in Operating System - HP-UX

gdb problem

Joseph Hoh — Thu, 21 Aug 2003 18:55:04 GMT

gdb pmdtm core08202003
Wildebeest is free software and you are welcome to distribute copies of
it under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for Wildebeest; type "show warranty"
for details.

Hewlett-Packard Wildebeest 1.0 (based on GDB 4.16)
(built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00)
Copyright 1996, 1997 Free Software Foundation, Inc...
(no debugging symbols found)...
Core was generated by `pmdtm'.
Program terminated with signal 6, Aborted.

warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

#0 0xc01f45a0 in _kill () from /usr/lib/libc.2
#0 0xc01f45a0 in _kill () from /usr/lib/libc.2
(gdb)

Re: gdb problem

Joseph Hoh — Thu, 21 Aug 2003 18:55:52 GMT

I forgot to ask the question.

How do I fix this problem?

Re: gdb problem

Mike Stroyan — Fri, 22 Aug 2003 14:29:28 GMT

The warning is because the text area of shared libraries is usually mapped read-only. The debugger needs writeable text to set a breakpoint. You can either restart the program from the debugger, or set a flag for writeable shared library text using '/opt/langtools/bin/pxdb -s on pmdtm'
before running the program.
(Newer chatr patches also add a 'chatr +dbg enable pmdtm' option to do the same thing.)

The breakpoint issue is not really an issue when you start the debugger on a core file. It can't continue from where the core happened. It can only examine what the process looked like when the core dump occured.

It looks like pmdtm may have dumped core in a call to abort. You should use gdb's bt command to see what the stack backtrace was at that time.