[Bug libc/387] New: ld-linux.so has its name in ro_data in link_map entry => problem in core files

[Bug libc/387] New: ld-linux.so has its name in ro_data in link_map entry => problem in core files

[jcownie at etnus dot com]

The dynamic linker ld-linux.so.2 is using a string in its .ro_data segment
as the target of the struct link_map entry which describes it.

This means that when core is dumped this name string is not in the core file 
(since only writeable segments are dumped).

When a core analysis tool (such as gdb) tries to interpret the chain of
link_map entries from the core file to determine which dynamic libraries
were loaded it has a bootstrap problem. The name of the dynamic linker's file
is in the file itself, and not in the core file.

In previous releases this name was not in the .ro_data segment, and therefore
was dumped to the core file avoiding the problem.

The proximate syptom is the message 

   warning: current_sos: Can't read pathname for load map: Input/output error

from gdb when trying to debug a core file, however the cause
is the change in the dynamic linker which has removed necessary information
from the core file.

-- 
           Summary: ld-linux.so has its name in ro_data in link_map entry =>
                    problem in core files
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: jcownie at etnus dot com
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: i686-suse-linux
  GCC host triplet: i686-suse-linux
GCC target triplet: i686-suse-linux


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2004-09-26 12:14 -------
Live with it.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[jcownie at etnus dot com]

------- Additional Comments From jcownie at etnus dot com  2004-09-27 09:40 -------
(In reply to comment #1)
> Live with it.

OK, fine. 

This, of course means that core files are useless for debugging problems
in the ld-linux, but then I suppose it's always perfect ;-)

It also reflects a _regression_ in behaviour. Reasonable things which you used
to be able to do are no longer feasible, but it's your product so if you want
to remove such reasonable capabilities and make gdb look broken that's your call.



-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2004-09-27 09:51 -------
If anything this sounds like a kernel bug to me.
It should dump even read-only VMAs that are MAP_PRIVATE and have been modified
(i.e. they contain data that you can't get from other sources).

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[jcownie at etnus dot com]

------- Additional Comments From jcownie at etnus dot com  2004-09-27 10:31 -------
Subject: Re:  ld-linux.so has its name in ro_data in link_map entry => problem in core files 

> If anything this sounds like a kernel bug to me.
> It should dump even read-only VMAs that are MAP_PRIVATE and have been modified
> (i.e. they contain data that you can't get from other sources).

The relevant function in the kernel appears to be this (fs/binfmt_elf.c)

989 /*
990  * Decide whether a segment is worth dumping; default is yes to be
991  * sure (missing info is worse than too much; etc).
992  * Personally I'd include everything, and use the coredump limit...
993  *
994  * I think we should skip something. But I am not sure how. H.J.
995  */
996 static int maydump(struct vm_area_struct *vma)
997 {
998         /*
999          * If we may not read the contents, don't allow us to dump
1000          * them either. "dump_write()" can't handle it anyway.
1001          */
1002         if (!(vma->vm_flags & VM_READ))
1003                 return 0;
1004 
1005         /* Do not dump I/O mapped devices! -DaveM */
1006         if (vma->vm_flags & VM_IO)
1007                 return 0;
1008 #if 1
1009         if (vma->vm_flags & (VM_WRITE|VM_GROWSUP|VM_GROWSDOWN))
1010                 return 1;
1011         if (vma->vm_flags & (VM_READ|VM_EXEC|VM_EXECUTABLE|VM_SHARED))
1012                 return 0;
1013 #endif
1014         return 1;
1015 }

It seems you're suggesting that the condition on line 1011 needs
changing ?

The inclusion of VM_READ there seems a little odd to me anyway, since we
already know (from the test at line 1002) that VM_READ must be set, and
therefore the whole test at line 1011 is guaranteed to succeed and cause
the function to return 0.



-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2004-09-28 01:03 -------
Created an attachment (id=205)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=205&action=view)
proposed linux 2.6 patch

How do you like this patch?  It works ok for me.  I will propose it to Linus.


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[jcownie at etnus dot com]

------- Additional Comments From jcownie at etnus dot com  2004-09-28 08:47 -------
Subject: Re:  ld-linux.so has its name in ro_data in link_map entry => problem in core files 


> How do you like this patch?  It works ok for me.  I will propose it to Linus.

I am slightly nervous abot two things in the patch.

1) If the comment in the old version of the function that attempting to
   dump non-readable sections fails, it seems reasonable to keep the
   test for readable in there.

2) I'm concerned that the test for COW may lead to you dumping things
   you didn't want to. Specifically consider things like shared text
   segments which have had pages duplicated because a debugger has
   planted a breakpoint in there. Historical precedent is not to dump
   these, even though they may pass your test for COW.



-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2004-09-28 09:38 -------
1) I think that old comment is in fact inaccurate now.
2) It is better to err on the side of including data rather than omitting.
>From the information the kernel vm has, there is no difference between the
example of ptrace-poked readonly pages and the relro pages that you do want in
the dump.


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[jcownie at etnus dot com]

------- Additional Comments From jcownie at etnus dot com  2004-09-28 09:49 -------
Subject: Re:  ld-linux.so has its name in ro_data in link_map entry => problem in core files 

OK, go for it !

> 2) It is better to err on the side of including data rather than
>    omitting.

Agreed, provided that we're not going to err too far on the side of
safety and dump a lot of information we genuinely don't need (like the
unmodified text segment, which can reasonably be got from the executable
image).



-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/387] ld-linux.so has its name in ro_data in link_map entry => problem in core files

[jcownie at etnus dot com]

------- Additional Comments From jcownie at etnus dot com  2004-09-28 10:12 -------
Subject: Re:  ld-linux.so has its name in ro_data in link_map entry => problem in core files 

One other thing which you should check is that your new code still dumps
the vDSO (system call) page (at 0xffffe000 in the current x86
implementation). 

The debugger needs that, and I'm unclear about how it's put in the
process' address space via the VM system, and therefore whether you'll
dump it.



-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=387

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.