This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/10088] on s390x, the translator gets an assertion
- From: "mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 22 Apr 2009 10:58:57 -0000
- Subject: [Bug translator/10088] on s390x, the translator gets an assertion
- References: <20090421180745.10088.dsmith@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From mjw at redhat dot com 2009-04-22 10:58 -------
(In reply to comment #1)
> I fixed the crash in elfutils git, for 0.141 when it comes (soonish).
>
> But this hits from a call to dwfl_module_address_section in dump_unwindsyms on
> the "kernel" (vmlinux) module. IMHO it should not be calling
> dwfl_module_address_section for any non-ET_REL module (i.e. non-.ko). If that's
> fixed it won't provoke the bug on the older elfutils libraries.
You are right, that logic was trying too be way too clever, it should just see
that dwfl_module_relocations() returned <= 1 relocation sections and then not
call it. Fixed in:
commit eadbd95761af3c2815e1b36df5a7d18dd28112a4
Author: Mark Wielaard <mjw@redhat.com>
Date: Wed Apr 22 12:53:39 2009 +0200
Simplify section size logic.
* translate.cxx (dump_unwindsyms): Just check that dwfl_module_relocations()
return more than 1 relocation section bases before calling
dwfl_module_address_section().
That works fine with 0.140 or before your last elfutils commit. But with your
latest fix applied you will hit the new assert in __libdwfl_relocate_value for
mod->e_type == ET_REL. The problem is the kernel module which isn't ET_REL. But
when dwfl_module_address_section() is called on an ET_REL kernel module it might
end up going through resolve_symbol() for that module, which loops through the
dwfl->modulelist and ends up trying to call __libdwfl_relocate_value on some
kernel module value.
The test cases that fail in the above manner, on x86_64, with elfutils tip
(19a8e4db) are precisely those of comment #1, on s390, so at least the failures
are consistent per platform now.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10088
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.