No crash log. No stack trace. How to debug crash during idle?

[Son of a Beach]

My app is crashing while idle about 30 seconds after starting up, and after having done no UI interaction with it at all.

There is no crash log saved, and in XCode there is no debug stack trace, and nothing at all in the debug console.

Can anybody give me any hints on the correct way to debug this crash?

(Unfortunately, I cannot figure out what I've changed that may have caused a crash, either, as I'm returning to this project after a few months off).

When I run the app in XCode (using a real device), I get the following in the console, with several seconds of nothing (after the app is up and running and before the crash), and the last line (gdb prompt) appearing at the time the app crashes.

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Fri Sep 16 06:56:50 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-apple-darwin --target=arm-apple-darwin".tty /dev/ttys000
sharedlibrary apply-load-rules all
target remote-mobile /tmp/.XcodeGDBRemote-39882-59
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
[Switching to process 7171 thread 0x1c03]
[Switching to process 7171 thread 0x1c03]
Re-enabling shared library breakpoint 2
Pending breakpoint 1 - "malloc_error_break" resolved
wait_fences: failed to receive reply: 10004003
(gdb)

If I try to do a (gdb) backtrace, I get:

(gdb) backtrace
No stack.
(gdb)

[Son of a Beach]

I'm guessing it may be getting killed by the iOS for using to much RAM. I guess I can try to analyse this with Instruments. I'll give that a go.

EDIT: Nope... Instruments shows no unusual memory usage. It seems to be using about half of what Springboard is using at the time of the crash, and did not use any more than that earlier.

I'm really stuck here, and would be grateful for any suggestions.

[Son of a Beach]

Of course it's not actually completely idle. There is stuff going on on background threads. The UI is fully responsive during this time, but background threads are busy doing callbacks for things that should be drawn on the screen. But none of those things ever actually get drawn before the crash (although they used to work just fine). The actual drawInRect: methods appear to be running to completion, when debugging.

So I'm guessing it's something to do with this background activity of data gathering and drawing, but I've no idea how to narrow it down further than that in any rational organised way (apart from putting in so many random break points that the app simply can't get on with doing anything at all without me clicking "continue").

[BrianSlick]

Nothing like spreading a few NSLogs around to track down problems.

[Son of a Beach]

Is there any way to get XCode to give any feedback whatsoever about the crash though?

I mean, I'm getting nothing. NOTHING apart from the (gdb) prompt. It's as though XCode thinks it is still all running perfectly fine, apart from that prompt.

[BrianSlick]

Not that I know of.

[Son of a Beach]

Using a whole lot of NSLogs may be the only option. But that's going to be very painful indeed. For starters, I'm going to have to put them everywhere, and then I'm going to get reams of output, and trying to figure out what output is missing is going to be the issue. I'm not sure how workable that is, but I may just have to try it. :-(

[BrianSlick]

Gosh, if only someone had provided a free utility that would help.

[Son of a Beach]

XCode and GDB are free utilities. I was hoping they could help. But apparently not. :-(

[BrianSlick]

*cough* ------------------------------->vvvvvvvvvvvv

[rocotilos]

Originally Posted by BrianSlick

*cough* ------------------------------->vvvvvvvvvvvv

Yup, you need to change the colors of those. People are not noticing them enough.

[Son of a Beach]

Heheh... OK fair enough. :-D

You've gotta make much stronger hints than that for me to notice what you're talking about. :-)

OK, I'll have a look at it. Does it log when leaving a method by premature "return" calls that are not right at the end of a method? Your topic probably covers, that... I'll go read up.

[Son of a Beach]

Well... instead of using logging, I'm having a fair bit of success in narrowing it down by using extra "return;" or "return nil;" statements at various places in suspect classes/methods.

After some initial experimenting with which class and method to start with, I've now worked through a stack of methods, isolating it down to one additional line of code in a method, and then doing the same again with the method called in that line, repeatedly through several layers of method calls.

I think I'm getting close! :-)

Still at a loss as to why XCode could not isolate this issue, nor even output anything at all in the console. Perhaps when I eventually track it down completely, I'll figure that out too.

[Son of a Beach]

Well, the mystery just deepens for me...

I've isolated it down to TWO lines of code:

NSLog(@"ONE");
self.tableOffsets = [NSArray array];
NSLog(@"TWO");
self.fileHandle = [NSFileHandle fileHandleForReadingAtPath:path];
NSLog(@"THREE");

(this method gets called many, many times, but always in a @synchonized block)

The crash can occur on either the array allocation or the filehandle allocation - it is inconsistent. This implies that it may be a memory issue. However, Instruments says there are no leaks (no surprise - I'm using ARC), and that the total allocations is only 1.35 MB.

Additionally, there are no memory warnings received.

So it doesn't quite fit with high memory usage.

I'm very confused. Anybody got any other ideas?

[Son of a Beach]

Using @try/@catch doesn't catch it either:

@try
{
	NSLog(@"ONE");
	self.tableOffsets = [NSArray array];
	NSLog(@"TWO");
	self.fileHandle = [NSFileHandle fileHandleForReadingAtPath:path];
	NSLog(@"THREE");
	self.fileLength = [fileHandle seekToEndOfFile];
	[fileHandle seekToFileOffset:0];
}
@catch (NSException *e)
{
	NSLog(@"Failed to initialise reader - failed to initialise file handle:  %@", [path lastPathComponent]);
	return nil;
}

Still just crashes in either of the same two places.

This further implies that the iOS is unceremoniously killing it (which implies RAM issues?), but I'm not getting any warnings or notifications about this. No crash logs. No GDB/XCode debug output. NOTHING.

Has anybody come across anything like this?

(I may need to start a new thread on this, now that I've isolated it a bit further).