Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?
Martin Langhoff
martin.langhoff at gmail.com
Sat Mar 17 10:51:33 EDT 2012
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
<jan.kratochvil at redhat.com> 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
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
--
martin.langhoff at gmail.com
martin at laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
More information about the Devel
mailing list