public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* Re: [PATCH] Fix bug using dwarf_next_unit to iterate over .debug_types
       [not found]       ` <87wr6eatmh.fsf_-_@fleche.redhat.com>
@ 2012-04-12 22:22         ` Josh Stone
  2012-04-13 10:18           ` Mark Wielaard
  0 siblings, 1 reply; 2+ messages in thread
From: Josh Stone @ 2012-04-12 22:22 UTC (permalink / raw)
  To: Tom Tromey; +Cc: elfutils-devel, SystemTap

On 03/21/2012 07:54 AM, Tom Tromey wrote:
> If you call dwarf_next_unit to iterate over .debug_types, then call
> dwarf_offdie_types, you can see a failure if some earlier call
> happened to call __libdw_intern_next_unit via dwarf_formref_die.
> 
> What happens is that __libdw_intern_next_unit updates the Dwarf's
> next_tu_offset, but does not add the TU to the TU search tree.  So,
> the call to dwarf_offdie_types does not find the TU in the tree, and
> will not search any more, causing a failure.

Hi Tom, can you clarify this failure mode?

I'm seeing a segfault in your debugtypes.exp test added to systemtap,
with my poor unpatched elfutils-0.153 on F16.  The call to
dwarf_offdie_types is returning NULL, which the calling code is not
prepared for.

So is the NULL return the extent of the failure?  Or is elfutils
generally borked after that?

And even apart from this bug, should we be ready for NULL return from
dwarf_offdie_types() anyway?  Same question for dwarf_offdie(), I guess.

Thanks,
Josh

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] Fix bug using dwarf_next_unit to iterate over .debug_types
  2012-04-12 22:22         ` [PATCH] Fix bug using dwarf_next_unit to iterate over .debug_types Josh Stone
@ 2012-04-13 10:18           ` Mark Wielaard
  0 siblings, 0 replies; 2+ messages in thread
From: Mark Wielaard @ 2012-04-13 10:18 UTC (permalink / raw)
  To: Josh Stone; +Cc: Tom Tromey, elfutils-devel, SystemTap

On Thu, 2012-04-12 at 15:22 -0700, Josh Stone wrote:
> I'm seeing a segfault in your debugtypes.exp test added to systemtap,
> with my poor unpatched elfutils-0.153 on F16.  The call to
> dwarf_offdie_types is returning NULL, which the calling code is not
> prepared for.
> 
> So is the NULL return the extent of the failure?  Or is elfutils
> generally borked after that?
> 
> And even apart from this bug, should we be ready for NULL return from
> dwarf_offdie_types() anyway?  Same question for dwarf_offdie(), I guess.

NULL can be returned fir dwarf_offdie () or dwarf_offdie_types () when
you give an offset that isn't really a DIE offset inside the debug_info
or debug_types section or when invalid DWARF is encountered. In such
cases NULL is returned and dwarf_errno () is set. The bug was in the
code that associated the right CU or TU with the returned Dwarf_Die. The
CU/TU is cached, but before the bug the cache could become bad and then
even valid offsets could fail, but the bug only impacted
dwarf_offdie_types ().

Cheers,

Mark

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-04-13 10:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <87k42gmq7v.fsf@fleche.redhat.com>
     [not found] ` <20120319214954.GE12114@toonder.wildebeest.org>
     [not found]   ` <87r4wnks8c.fsf@fleche.redhat.com>
     [not found]     ` <20120320203315.GB1650@toonder.wildebeest.org>
     [not found]       ` <87wr6eatmh.fsf_-_@fleche.redhat.com>
2012-04-12 22:22         ` [PATCH] Fix bug using dwarf_next_unit to iterate over .debug_types Josh Stone
2012-04-13 10:18           ` Mark Wielaard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).