This is the mail archive of the
mailing list for the elfutils project.
Re: [patch] Detect infinite backtraces
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 21 Jan 2014 17:04:32 +0100
- Subject: Re: [patch] Detect infinite backtraces
On Mon, 2014-01-20 at 15:48 +0100, Jan Kratochvil wrote:
> On Mon, 20 Jan 2014 11:08:45 +0100, Mark Wielaard wrote:
> > On Sat, 2014-01-18 at 21:53 +0100, Jan Kratochvil wrote:
> > > OK, so the patch can also already implement the GDB logic:
> > > https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ebedcab50d2c7699ced23f4cf4eae712c0a9ca40
> > That is not very pretty. Lets just make sure unwinding works normally in
> > all cases, so we don't need such hacks.
> "very pretty" is not a pragmatic engineering decision. Could there be given
> more factual rasons?
Sorry I thought that was obvious. It disables consistency checking
completely when a magic symbol can be found. That IMHO is two wrongs.
First it shows there is something wrong with the consistency checking
because it checks something that isn't always actually wrong. Secondly
it introduces symbol lookups in the middle of an frame unwind, making it
depend on symbol resolution which looks like a layering violation.
> > Yes, given that you don't have a defined ordering for the CFA values.
> arch/ebl can define it.
It might be able to define something like a frame identity depending on
arch specific registers in a frame. So you could use that to
compare/detect previously seen frames. But I don't immediately see how
you can define an ordering. What do you suggest to use as ordering
> > You could check all previous frames to check for duplicate values. But
> > that seems wasteful given that backtraces can be pretty deep.
> There is dynamicsizehash.[ch] which can handle it fast enough.
OK, but it might still take up a lot of memory. Although I guess you
could restrict it to just the last few frames.
> The problem is that as long as there is no real fix for infinite backtraces
> one cannot get rid of the broken '-n MAXFRAMES' option. One may speculate
> the purpose of blocking real infinite backtrace fix is to keep the broken
> '-n MAXFRAMES' option in place.
You speculate wrongly. Please stop that. Concentrate on the technical
I don't think these things are really related. One is a low-level
consistency check in an internal implementation of a library, the other
is a user command line option default. Both are good to have, they are
just at different abstraction layers.
> > > Right, that's why SP was not used in that patch.
> > Lets see whether we need it or not.
> As long as there is a requirement to handle non-CFA defining frames (which
> I have no idea whether exist in real world or not) then SP is required from
> the backend.