wrote: >=20 >> On Thu, Dec 26, 2013 at 09:13:59PM -0600, James Gregurich wrote: >>>=20 >>>=20 >>> When I debug my app in gdb, I consistently get =93Backtrace stopped: >>> previous frame inner to this frame (corrupt stack?)=94 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. >>=20 >> 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. >>=20 >> Rich >=20 --Apple-Mail=_47D9B125-0F0E-4325-9193-C7576E06B7B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

a = followup=85

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=3D0x0, dmxData=3D0x19cea20 "")

at <source = location>

#1 0x0182e5e0 in c::f = (this=3D0x1a1e860,

= enabledPorts=3D0x48015cb8)

at <source = location>

#2 0x0182e4c0 in c::f (this=3D<optimized = out>)

at <source location>

#3 = 0x0181fdd8 in c::f (this=3D<optimized out>)

= at <source location>

#4 0x0181faf4 in c::f = (arg=3D0x1a1e860)

at <source location>

#5 = 0x0190ff20 in start (p=3D0x48015d40) 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 = =93Backtrace stopped:
previous frame inner to this frame (corrupt = stack?)=94 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

= --Apple-Mail=_47D9B125-0F0E-4325-9193-C7576E06B7B0--