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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- martin.langhoff@xxxxxxxxx martin@xxxxxxxxxx -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
