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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
martin.langhoff(a)gmail.com
martin(a)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