1833861 Members
2579 Online
110063 Solutions
New Discussion

Re: gdb problem

 
Joseph Hoh
Frequent Advisor

gdb problem

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)
2 REPLIES 2
Joseph Hoh
Frequent Advisor

Re: gdb problem

I forgot to ask the question.

How do I fix this problem?
Mike Stroyan
Honored Contributor

Re: gdb problem

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.