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 #1 0x0182e5e0 in c::f (this=0x1a1e860, enabledPorts=0x48015cb8) at #2 0x0182e4c0 in c::f (this=) at #3 0x0181fdd8 in c::f (this=) at #4 0x0181faf4 in c::f (arg=0x1a1e860) at #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 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 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 >