[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <7F719E8E-5B66-4A9A-AB4C-8505740090C4@mac.com>
Date: Fri, 27 Dec 2013 16:34:30 -0600
From: James Gregurich <bayoubengal@....com>
To: musl@...ts.openwall.com
Subject: Re: mistake in powerpc clone.s?
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@....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@...ifal.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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
