a followup…


GDB log example.  this is what one typically sees. I edited out the private source code info. A message like that can easily send one chasing wild geese when he is hunting for a fault.
 

(gdb) bt
#0  c::f (this=0x0, dmxData=0x19cea20 "")
    at <source location>
#1  0x0182e5e0 in c::f (this=0x1a1e860, 
    enabledPorts=0x48015cb8)
    at <source location>
#2  0x0182e4c0 in c::f (this=<optimized out>)
    at <source location>
#3  0x0181fdd8 in c::f (this=<optimized out>)
    at <source location>
#4  0x0181faf4 in c::f (arg=0x1a1e860)
    at <source location>
#5  0x0190ff20 in start (p=0x48015d40) at src/thread/pthread_create.c:104
#6  0x01922e54 in clone ()
Backtrace stopped: frame did not save the PC
(gdb) 




On Dec 26, 2013, at 9:45 PM, James Gregurich <bayoubengal@mac.com> wrote:

If you want me to try a patch, let me know.

BTW: I have an actual crash in my app that appears to be a stack corruption. I was following up on that message to see if it was relevant to the crash.

-James


On Dec 26, 2013, at 9:42 PM, Rich Felker <dalias@aerifal.cx> wrote:

On Thu, Dec 26, 2013 at 09:13:59PM -0600, James Gregurich wrote:


When I debug my app in gdb, I consistently get “Backtrace stopped:
previous frame inner to this frame (corrupt stack?)” at the lower
end of the backtrace. I set break points at each function in the
back trace and that message persists up to the __clone() invocation.
until that line that I pointed out, the backtrace is normal. Once
that instruction is executed, the backtrace is permanently broken
for that thread.

In the backtrace for a thread other than the main thread, it's normal
and expected for the backtrace to end at __clone; it's where the
thread started. The "corrupt stack" message is unwanted (musl should
be arranging for the frame pointer to be zero so that debuggers
recognize that there's nothing else on the stack, and maybe this needs
fixing) but I don't think it's necessarily indicative of any bug.

Rich