Re: Getting poor stack traces
Re: Getting poor stack traces
- Subject: Re: Getting poor stack traces
- From: Michael Crawford <email@hidden>
- Date: Tue, 30 Jul 2013 21:13:28 +0000
In your Xcode project settings, do you enable Stack Frames in your
machine code generation? I don't know what the actual setting will be
called in the current Xcode, but most compilers permit one to enable
or disable them.
In general, stack frames are not actually necessary to get one's code
just to execute correctly - one can use just the Stack Pointer,
without at the same time using a Stack Frame - however Frames are
generally required for the generation of useful stack traces.
You could instead use some manner of logging, in hopes that rather
than a stack trace, your logs will show what was going on before your
break.
If you find your logs are too verbose, rather than emitting all the
logs, write into a circular buffer that you dump out at your
breakpoint. Adjust the capacity of your buffer so that it logs
enough, but not so much that you are overwhelmed with useless
information.
If your logging slows down your code unacceptably, or you are working
with real-time code that will not perform correctly if you slow it
down, rather than writing variable-length text messages, instead write
fixed-size binary structures. I used such a fixed-record-size
circular buffer _incredibly_ helpful when I was debugging the test
tool we used at Apple, to test MacTCP.
I have the source to a fast thread-safe circular buffer I can dig up
and give you if you like. Presently it supports sixteen-bit integer
records, for buffering CD-quality audio, but it would be easy to adapt
for other purposes. My present implementation uses a semaphore to
block the input when it's full, and will feed silence - zeroes - to
the output when its empty, but again one could easily change that, for
example to just lose the oldest records when it's full, rather than
blocking.
I don't know that I could actually dig up the source, but I also once
wrote a circular buffer around the C++ Standard Template Library
std:vector, that was itself an STL-compatible template, so that one
could combine it with the same STL algorithms that one normally uses
with vectors, deques, lists and so on.
Finally, while it would be a huge PITA, it is in principle possible to
implement your own stack trace. Perhaps doing so would yield
intelligible results, that are otherwise unobtainable from Xcode.
On Tue, Jul 30, 2013 at 8:30 PM, Rick Mann <email@hidden> wrote:
> I'm trying to debug a problem where I'm inserting nil into a placeholder array. I break on exceptions, and it stops dutifully, but the stack is useless. So I set a symbolic breakpoint on -[__NSPlaceholderArray initWithObjects:count:]. It stops just fine, but again, the stack seems truncated:
>
> (lldb) bt
> * thread #1: tid = 0x2403, 0x32ffe2a8 CoreFoundation`-[__NSPlaceholderArray initWithObjects:count:], stop reason = breakpoint 3.1
> frame #0: 0x32ffe2a8 CoreFoundation`-[__NSPlaceholderArray initWithObjects:count:]
> frame #1: 0x32ffe1bc CoreFoundation`+[NSArray array] + 40
> frame #2: 0x34ecd2be UIKit`+[UIWindow allWindowsIncludingInternalWindows:onlyVisibleWindows:] + 66
>
> In this case, the call is fine and will execute normally, so there's no stack corruption going on (yet). I don't think there was any even after the exception I'm encountering.
>
> Is there anything I can do?
>
> --
> Rick
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden