I implemented a magic ring buffer (MRB) on linux using memfd_create, ftruncate, mmap, and munmap. The fd returned by memfd_create gets close()'d after the buffer is fully constructed. The MRB itself runs and works perfectly fine.

The problem:

1. One tries to create a core-file on a process running this MRB with gcore.
2. They then try to use gdb <executable> -c <core-file>

gdb then prints a warning:

warning: Can't open file /memfd:magicringbuffer (deleted) during file-backed mapping note processing

Additional notes:

• "magicringbuffer" is the string passed as the name parameter in memfd_create(const char *name, unsigned int flags);
• built and run on CentOS version 7

Questions:

• What does this warning exactly mean? What causes it? Is it because the "file" is virtual? or because it was close()'d?
• What are the implications of it? Could it lead to missing debug symbols? The <executable> is indeed a binary with debug symbols

I tried to look for an answer on the internet, but I found nothing satisfactory.

CodePudding user response：

GDB is trying to reconstruct the virtual address space of the former process, at the time of the core dump, as accurately as possible. This includes re-creating all mmap regions. The message means simply that GDB tried, and failed, to re-create the mmap region that was backed by the memfd. IIRC, the annotation in the core file that tells GDB that an mmap region existed -- the "file-backed mapping note" -- was designed before memfd_create was a thing, and so GDB doesn't know it should be calling memfd_create() instead of regular old open() for this one. And even if it did, it wouldn't be able to recover access to the original memfd area (which might be completely gone by the time you get around to debugging from the core dump).

The practical upshot of this is that, while debugging from the core dump, you won't be able to look at the contents of memory within your magic ring buffer. Debug symbols, however, should be unaffected.

This is arguably a bug in either the kernel or gcore (not sure which); the contents of memfd-backed memory regions should arguably be dumped into the core file like MAP_ANONYMOUS regions, rather than generating file-backed mapping notes.