This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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]

backtrace() from a pthread on ARM


I'm working on an ARM product, which does quite a bit of automated
crash reporting using backtrace().  We've noticed some odd behavior in
this function when the thread in question was created as a pthread (as
opposed to being the process's main thread.)  The reported backtrace
will generally go down correctly through the various frames until it
hits the clone() call, which is effectively the beginning of the world
for this thread.  However we will often see stack frames beyond that
one, which are generally complete garbage.  We have also on a couple
of occasions actually observed the backtrace() function crashing while
trying to walk through these garbage frames.

Some examination of the call stack of the thread shows that, in the
top frame of the stack, there is a non-empty value in the frame
pointer slot--specifically, a pointer which points back into the main
thread's stack.  It seems that, after the clone() call is made, no
attempt is made to modify the value of r11 in the newly-created
thread, so when the first call is made from that thread, it saves an
activation record with a saved frame pointer which points back to the
stack of the originating thread.  When backtrace() tries to follow
this, it happily walks back into the original stack segment, ending up
in strange code at best, or read-protected garbage at worst.

My question is, first of all, is there any ARM ABI (or other
equivalent) requirement as to what the frame pointer needs to be in
newly-created threads?  It seems like it would be beneficial for the
backtrace logic if it were set to an invalid value, so that attempts
to walk back across the stack would terminate correctly when the
beginning of the call stack was reached.  I'm not an expert in this
area, so perhaps I'm just misunderstanding what ought to happen here,
but in general, is there a way that this is supposed to work
correctly, or is it just broken by design?

Many thanks,
Matt


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