Re: mistake in powerpc clone.s?

[James Gregurich <bayoubengal@mac.com>]

[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

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
> 


[-- Attachment #2: Type: text/html, Size: 3916 bytes --]