Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Jan Kratochvil]

On Fri, 16 Mar 2012 20:46:16 +0100, Martin Langhoff wrote:
> Argh, that could be. But our kernel is a custom built rpm,

You have a bug for Fedora there, in the core file by readelf -l:
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  LOAD          0x1933000 0xa7703000 0x00000000 0x00000 0x174000 R E 0x1000
                                                ^^^^^^^
There is normally 0x1000 on x86* Fedora kernels due to:
$ cat /proc/self/coredump_filter 
00000033

/usr/share/doc/kernel-doc-*/Documentation/filesystems/proc.txt
  - (bit 4) ELF header pages in file-backed private memory areas (it is
            effective only if the bit 2 is cleared)

This way build-id for the executable and shared libraries is dumped in the
core file but it is missing in this OLPC kernel.  Fedora GDB has not yet
upstreamed patch for build-id which did not expect such core files.

Going to push a fix for F-15+ but F-14 is EOLed, you can either use FSF GDB or
patch Fedora GDB by this patch or use F-15+ GDB etc.

That backtrace of "core.522" FYI is at:
	http://people.redhat.com/jkratoch/sandisk.bt


Thanks,
Jan
-------------- next part --------------
--- gdb-7.2/gdb/solib-svr4.c.orig	2012-03-17 09:39:54.874090162 +0100
+++ gdb-7.2/gdb/solib-svr4.c	2012-03-17 09:42:12.561810807 +0100
@@ -1202,14 +1202,30 @@ svr4_current_sos (void)
 	    }
 	  else
 	    {
-	      struct build_id *build_id;
+	      struct build_id *build_id = NULL;
 
 	      strncpy (new->so_original_name, buffer, SO_NAME_MAX_PATH_SIZE - 1);
 	      new->so_original_name[SO_NAME_MAX_PATH_SIZE - 1] = '\0';
 	      /* May get overwritten below.  */
 	      strcpy (new->so_name, new->so_original_name);
 
-	      build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
+	      /* In the case the main executable was found according to its
+		 build-id (from a core file) prevent loading a different build
+		 of a library with accidentally the same SO_NAME.
+
+		 It suppresses bogus backtraces (and prints "??" there instead)
+		 if the on-disk files no longer match the running program
+		 version.
+		 
+		 If the main executable was not loaded according to its
+		 build-id do not do any build-id checking of the libraries.
+		 There may be missing build-ids dumped in the core file and we
+		 would map all the libraries to the only existing file loaded
+		 that time - the executable.  */
+
+	      if (symfile_objfile != NULL
+		  && (symfile_objfile->flags & OBJF_BUILD_ID_CORE_LOADED) != 0)
+		build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
 	      if (build_id != NULL)
 		{
 		  char *name, *build_id_filename;
@@ -1224,23 +1240,7 @@ svr4_current_sos (void)
 		      xfree (name);
 		    }
 		  else
-		    {
-		      debug_print_missing (new->so_name, build_id_filename);
-
-		      /* In the case the main executable was found according to
-			 its build-id (from a core file) prevent loading
-			 a different build of a library with accidentally the
-			 same SO_NAME.
-
-			 It suppresses bogus backtraces (and prints "??" there
-			 instead) if the on-disk files no longer match the
-			 running program version.  */
-
-		      if (symfile_objfile != NULL
-			  && (symfile_objfile->flags
-			      & OBJF_BUILD_ID_CORE_LOADED) != 0)
-			new->so_name[0] = 0;
-		    }
+		    debug_print_missing (new->so_name, build_id_filename);
 
 		  xfree (build_id_filename);
 		  xfree (build_id);