[patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.

[patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.

[Jan Kratochvil]

Hi,

GDB currently always prints on loading a core file:
	warning: Can't read pathname for load map: Input/output error.

The patch is not nice but it was WONTFIXed on the glibc side in:
	http://sourceware.org/ml/libc-alpha/2009-10/msg00001.html

The same message in GDB PR 8882 and glibc PR 387 was for ld-linux.so.2 l_name
but that one is now ignored thanks to IGNORE_FIRST_LINK_MAP_ENTRY.

This fix is intended for Linux system vDSO l_name which is a second entry in
the DSO list.

Regression tested on {x86_86,x86_64-m32,i686}-fedora11-linux-gnu.


Thanks,
Jan


gdb/
2009-10-06  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Do not print false warning on reading core file with vDSO on GNU/Linux.
	* solib-svr4.c (svr4_current_sos): Suppress the warning if
	MASTER_SO_LIST is still NULL.
	* solib.c (update_solib_list): New variable saved_so_list_head.
	Conditionally restart the function.

--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1097,8 +1097,18 @@ svr4_current_sos (void)
 	  target_read_string (LM_NAME (new), &buffer,
 			      SO_NAME_MAX_PATH_SIZE - 1, &errcode);
 	  if (errcode != 0)
-	    warning (_("Can't read pathname for load map: %s."),
-		     safe_strerror (errcode));
+	    {
+	      /* During the first ever DSO list reading some strings may be
+		 unreadable as residing in the ld.so readonly memory not being
+		 present in a dumped core file.  Delay the error check after
+		 the first pass of DSO list scanning when ld.so should be
+		 already mapped in and all the DSO list l_name memory gets
+		 readable.  */
+
+	      if (master_so_list () != NULL)
+		warning (_("Can't read pathname for load map: %s."),
+			 safe_strerror (errcode));
+	    }
 	  else
 	    {
 	      strncpy (new->so_name, buffer, SO_NAME_MAX_PATH_SIZE - 1);
--- a/gdb/solib.c
+++ b/gdb/solib.c
@@ -538,6 +538,7 @@ update_solib_list (int from_tty, struct target_ops *target)
   struct target_so_ops *ops = solib_ops (target_gdbarch);
   struct so_list *inferior = ops->current_sos();
   struct so_list *gdb, **gdb_link;
+  struct so_list *saved_so_list_head = so_list_head;
 
   /* We can reach here due to changing solib-search-path or the
      sysroot, before having any inferior.  */
@@ -668,6 +669,12 @@ update_solib_list (int from_tty, struct target_ops *target)
 	  observer_notify_solib_loaded (i);
 	}
     }
+
+  /* If this was the very first DSO list scan and we possibly read in ld.so
+     recheck all the formerly unreadable DSO names strings.  */
+
+  if (saved_so_list_head == NULL && so_list_head != NULL)
+    update_solib_list (from_tty, target);
 }
 
 

Re: [patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.

[Paul Pluzhnikov]

Ping?

I see this all the time, and it causes end-user confusion.


On Tue, Oct 6, 2009 at 2:45 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hi,
>
> GDB currently always prints on loading a core file:
>        warning: Can't read pathname for load map: Input/output error.
>
> The patch is not nice but it was WONTFIXed on the glibc side in:
>        http://sourceware.org/ml/libc-alpha/2009-10/msg00001.html
>
> The same message in GDB PR 8882 and glibc PR 387 was for ld-linux.so.2 l_name
> but that one is now ignored thanks to IGNORE_FIRST_LINK_MAP_ENTRY.
>
> This fix is intended for Linux system vDSO l_name which is a second entry in
> the DSO list.

I believe the statement above is incorrect: the string comes from
read-only mapping of ld.so (as the comment in the patch correctly
says), and has nothing to do with vDSO.

>
> Regression tested on {x86_86,x86_64-m32,i686}-fedora11-linux-gnu.
>
>
> Thanks,
> Jan
>
>
> gdb/
> 2009-10-06  Jan Kratochvil  <jan.kratochvil@redhat.com>
>
>        Do not print false warning on reading core file with vDSO on GNU/Linux.

vDSO mention again ...

>        * solib-svr4.c (svr4_current_sos): Suppress the warning if
>        MASTER_SO_LIST is still NULL.
>        * solib.c (update_solib_list): New variable saved_so_list_head.
>        Conditionally restart the function.
>
> --- a/gdb/solib-svr4.c
> +++ b/gdb/solib-svr4.c
> @@ -1097,8 +1097,18 @@ svr4_current_sos (void)
>          target_read_string (LM_NAME (new), &buffer,
>                              SO_NAME_MAX_PATH_SIZE - 1, &errcode);
>          if (errcode != 0)
> -           warning (_("Can't read pathname for load map: %s."),
> -                    safe_strerror (errcode));
> +           {
> +             /* During the first ever DSO list reading some strings may be
> +                unreadable as residing in the ld.so readonly memory not being
> +                present in a dumped core file.  Delay the error check after
> +                the first pass of DSO list scanning when ld.so should be
> +                already mapped in and all the DSO list l_name memory gets
> +                readable.  */
> +
> +             if (master_so_list () != NULL)
> +               warning (_("Can't read pathname for load map: %s."),
> +                        safe_strerror (errcode));
> +           }
>          else
>            {
>              strncpy (new->so_name, buffer, SO_NAME_MAX_PATH_SIZE - 1);
> --- a/gdb/solib.c
> +++ b/gdb/solib.c
> @@ -538,6 +538,7 @@ update_solib_list (int from_tty, struct target_ops *target)
>   struct target_so_ops *ops = solib_ops (target_gdbarch);
>   struct so_list *inferior = ops->current_sos();
>   struct so_list *gdb, **gdb_link;
> +  struct so_list *saved_so_list_head = so_list_head;
>
>   /* We can reach here due to changing solib-search-path or the
>      sysroot, before having any inferior.  */
> @@ -668,6 +669,12 @@ update_solib_list (int from_tty, struct target_ops *target)
>          observer_notify_solib_loaded (i);
>        }
>     }
> +
> +  /* If this was the very first DSO list scan and we possibly read in ld.so
> +     recheck all the formerly unreadable DSO names strings.  */
> +
> +  if (saved_so_list_head == NULL && so_list_head != NULL)
> +    update_solib_list (from_tty, target);
>  }
>
>
>



-- 
Paul Pluzhnikov

Re: [patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.

[Jan Kratochvil]

On Tue, 17 May 2011 03:06:11 +0200, Paul Pluzhnikov wrote:
> I see this all the time, and it causes end-user confusion.

(a)
The fix should be in glibc and not in gdb but it was rejected in glibc.

(b) 
Loading libraries for a core file from the inferior solist stored in the core
file does not work anyway.  If you have a crashed application with memory
corruption commonly the inferior solist is also corrupted, GDB fails to find
the libraries, therefore fails to load relocated symbols and therefore fails
to display symbols for the backtrace.

The right approach is to map symbols for libraries according to their
build-ids (when available).  This is no longer dependent on the corrupted
solist.  And it is also no longer dependent on this glibc bug as the solist
will no longer get used (it will - to check for libraries not having
build-id).

Unfortunately the whole build-id locating patch is not yet in FSF GDB.
	http://sourceware.org/ml/gdb-patches/2010-11/msg00353.html
	http://sourceware.org/ml/gdb-patches/2010-11/msg00354.html
or:
	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-6.6-buildid-locate.patch;hb=f15
	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-6.6-buildid-locate-rpm.patch;hb=f15
	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-6.6-buildid-locate-rpm-librpm-workaround.patch;hb=f15
	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-6.6-buildid-locate-core-as-arg.patch;hb=f15

I do not yet have written the build-id extension for mapping solibs but I will
do it soon as it affects Fedora ABRT backtracing a lot.


Thanks,
Jan

Re: [patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.

[Paul Pluzhnikov]

On Tue, May 17, 2011 at 10:08 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 17 May 2011 03:06:11 +0200, Paul Pluzhnikov wrote:
>> I see this all the time, and it causes end-user confusion.
>
> (a)
> The fix should be in glibc and not in gdb but it was rejected in glibc.

In this particular case I believe Ulrich may be correct in rejecting
the patch.

> (b)
> Loading libraries for a core file from the inferior solist stored in the core
> file does not work anyway.  If you have a crashed application with memory
> corruption commonly the inferior solist is also corrupted,

While it's very possible for solist in the inferior to be corrupted, I've
never actually seen this happen in practice, and I do regularly look at
core dumps.

I wonder what makes corrupt solist in the inferior common for you.

> The right approach is to map symbols for libraries according to their
> build-ids (when available).

But until then, IWBN to not issue a warning in the common case.

-- 
Paul Pluzhnikov

Re: [patch] Fix GNU/Linux core open: Can't read pathname for load map: Input/output error.

[Jan Kratochvil]

On Tue, 17 May 2011 20:57:23 +0200, Paul Pluzhnikov wrote:
> I wonder what makes corrupt solist in the inferior common for you.

Reports in Fedora ABRT I was presented by the ABRT team.


> But until then, IWBN to not issue a warning in the common case.

I no longer push for it myself.


Thanks,
Jan