This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Detect infinite backtraces


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?


> Yes, given that you don't have a defined ordering for the CFA values.

arch/ebl can define it.


> 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.


> Just checking the last frame will probably catch most bad call stacks.

I do not think so, stack frames contain absolutely any value one can imagine.
Particularly one finds all close-to-SP and close-to-PC values at the top of
stack.


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.  Factual reasons why the '-n MAXFRAMES'
default is broken have been already discussed by multiple people at this list.


> > 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.


Trying to gather all the requirements and blocks on this feature to figure out
which variant of it would be acceptable.


Jan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]