Messages in this thread Patch in this message | | | Date | Thu, 06 Apr 2006 14:03:57 -0700 (PDT) | Subject | fs/binfmt_elf.c:maydump() | From | "David S. Miller" <> |
| |
I sort of understand the idea behind this check in maydump():
/* If it hasn't been written to, don't write it out */ if (!vma->anon_vma) return 0;
but it causes real problems for debugging. In fact a GDB testcase breaks because of this check.
In the GDB testcase, the application mmap()'s a file with some text in it. It then calls abort() to dump core. Then GDB loads up the application again using that core file, and it tries to look at the mmap()'d file, and that doesn't work. We don't dump the file contents because of the above check so GDB has no idea how to reproduce the application state at the time of the core dump.
Furthermore, it is vitally important to dump such areas to handle the case where the file contents change after the core dump occurs. So even if we had some way to tell GDB the full pathname of the file which was mapped at that location, we should still dump the contents and not try to elide them via this check in maydump().
Yes, this means we might hit the core dump limits quicker but we shouldn't be doing anything which makes less debugging information than necessary available. Software development is hard enough as it is right? :)
I also have a strange feeling that the VM_SHARED/i_nlink==0 check might cause similar problems, but I won't touch that for now.
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 537893a..7fea878 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -1167,10 +1167,6 @@ static int maydump(struct vm_area_struct if (vma->vm_flags & VM_SHARED) return vma->vm_file->f_dentry->d_inode->i_nlink == 0; - /* If it hasn't been written to, don't write it out */ - if (!vma->anon_vma) - return 0; - return 1; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |