This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug shlibs/16344] New: Linux /proc/PID/map_files/ for deleted files


https://sourceware.org/bugzilla/show_bug.cgi?id=16344

            Bug ID: 16344
           Summary: Linux /proc/PID/map_files/ for deleted files
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: shlibs
          Assignee: unassigned at sourceware dot org
          Reporter: jan.kratochvil at redhat dot com

Backtracing already deleted files does not work:

$ gdb -q -p $p
Attaching to process 12280
.../elfutils/tests/deleted (deleted): No such file or directory.
(gdb) bt
#0  0x472bd360 in ?? ()
Cannot access memory at address 0x2cc946e8

This commonly happens for long-term running processes/daemons which have been
nightly automatically upgraded or which have been nightly prelinked by prelink.

But it could work, recent Linux kernels support /proc/PID/map_files/
demonstrated by elfutils use:
 
https://lists.fedorahosted.org/pipermail/elfutils-devel/2013-December/003638.html

Current Linux kernels (3.11.10) permit only root user as the tracer but (1)
hopefully it gets fixed in the future and (2) at least for the use in ABRT it
is OK as backtracer is run from core dumping hook.

Linux kernels have always supported also /proc/PID/exe which works for deleted
main executable.  It even works for non-root users.  But it works only for the
executable, not for shared libraries.  I find more useful to push for Linux
kernel /proc/PID/map_files/ permissions fix than to implement /proc/PID/exe.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]