Messages in this thread | | | Date | Wed, 2 Jul 2008 15:16:52 +0200 | From | Philippe De Muyter <> | Subject | Re: mmap'ed memory in core files ? |
| |
On Wed, Jul 02, 2008 at 02:24:59PM +0200, Stefan Richter wrote: >>> On Wed, Jul 2, 2008 at 12:50 PM, Philippe De Muyter <phdm@macqel.be> >>> wrote: >>>> Hi Michael, >>>> >>>> On Tue, Jul 01, 2008 at 08:16:11PM +0200, Michael Kerrisk wrote: >>>>> Have a look at the section "Controlling which mappings are written to >>>>> the core dump" in a recent core.5 man page: >>>>> http://www.kernel.org/doc/man-pages/online/pages/man5/core.5.html >>>> thanks for the info. I didn't know about /proc/PID/coredump_filter. >>>> >>>> that part was promising : >>>> >>>> bit 2 Dump file-backed private mappings. >>>> bit 3 Dump file-backed shared mappings. >>>> >>>> The default value of coredump_filter is 0x3; this reflects >>>> traditional >>>> Linux behavior and means that only anonymous memory segments are >>>> dumped. >>>> >>>> Unfortunately, the part that applies to me (I have tested it) is the >>>> next one : >>>> >>>> Memory-mapped I/O pages such as frame buffer are never dumped, [...], >>>> regardless of the coredump_filter value. > > This shouldn't be a problem to you as far as I understand. I suppose > "memory mapped I/O pages" means registers of PCI devices, mapped into the > memory address space. > > The DMA buffer which you would like to get included in the core file is > normal RAM (I suppose: allocated by the kernel in the kernel's virtual > address space, mapped into the application client's address space by > mmap(), and also mapped into the FireWire controller's local bus address > space for it to write received data into).
I agree with your analysis, but the sentence takes as exemple 'frame buffer' which I don't think are registers. I have tested with a video1394 client, and I do not get the mmapped video memory in the core file, even with /proc/PID/coredump_filter set to 0xf. So, while I agree it seems technically feasible, it does not seem to be currently implemented :(
Philippe
| |