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

[Martin Langhoff]

Hi Jan,

that's enormously useful -- thanks! I'll make sure we fix our kernel
options so this isn't an issue in the future.

And I'll patch my gdb so I can read the other stacktraces.

cheers -

m

On Sat, Mar 17, 2012 at 4:56 AM, Jan Kratochvil
 wrote:
> 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
>
> --- 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);
>
> --
> devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/devel