Debug Crash on load - how to debug

Hello all,

I`m getting a strange crash on the app load and it creates a .crash file with a lot of data there.

Anyone has any idea how to debug that ?

what i get is

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000004200000

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x9b9878d3 __CFStringDecodeByteStream3 + 3027
1 com.apple.CoreFoundation 0x9b93b789 __CFStringCreateImmutableFunnel3 + 1097
2 com.apple.CoreFoundation 0x9b94e460 CFStringCreateWithBytes + 96
3 com.xojo.XojoFramework 0x01a8bad1 0x1a15000 + 486097
4 com.xojo.XojoFramework 0x01a454b0 0x1a15000 + 197808
5 com.apple.AppKit 0x99e3f463 -[NSComboBox(NSComboBoxCellDataSource) comboBoxCell:objectValueForItemAtIndex:] + 48
6 com.apple.AppKit 0x99e45a3d -[NSComboBoxCell(NSTableDataSource) tableView:objectValueForTableColumn:row:] + 48
7 com.apple.AppKit 0x99b96305 -[NSTableView _dataSourceValueForColumn:row:] + 69
8 com.apple.AppKit 0x99c9a127 -[NSTableView preparedCellAtColumn:row:] + 385
9 com.apple.AppKit 0x99c99e25 -[NSTableView _drawContentsAtRow:column:withCellFrame:] + 50
10 com.apple.AppKit 0x99c99bf2 -[NSTableView drawRow:clipRect:] + 1502
11 com.apple.AppKit 0x99c994bf -[NSTableView drawRowIndexes:clipRect:] + 801
12 com.apple.AppKit 0x99b6cc94 -[NSTableView drawRect:] + 1254
13 com.apple.AppKit 0x99b52194 -[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inGraphicsContext:CGContext:topView:shouldChangeFontReferenceColor:] + 1174
14 com.apple.AppKit 0x99b51bec __46-[NSView(NSLayerKitGlue) drawLayer:inContext:]_block_invoke + 220
15 com.apple.AppKit 0x99b51971 -[NSView(NSLayerKitGlue) _drawViewBackingLayer:inContext:drawingHandler:] + 2237
16 com.apple.AppKit 0x99b510a8 -[NSView(NSLayerKitGlue) drawLayer:inContext:] + 116
17 com.apple.AppKit 0x99b51029 -[NSViewBackingLayer drawInContext:] + 65
18 com.apple.QuartzCore 0x9b42763c backing_callback(CGContext*, void*) + 96
19 com.apple.QuartzCore 0x9b2c9613 CABackingStoreUpdate
+ 3887
20 com.apple.QuartzCore 0x9b2c86dc __ZN2CA5Layer8display_Ev_block_invoke + 93
21 com.apple.QuartzCore 0x9b2c8672 x_blame_allocations + 88
22 com.apple.QuartzCore 0x9b2c813d CA::Layer::display
() + 1641
23 com.apple.QuartzCore 0x9b2c7acd -[CALayer _display] + 20
24 com.apple.QuartzCore 0x9b2c7ab0 CA::Layer::display() + 184
25 com.apple.QuartzCore 0x9b2c79f0 -[CALayer display] + 20
26 com.apple.AppKit 0x99b50f5a _NSBackingLayerDisplay + 670
27 com.apple.AppKit 0x99b50cb7 -[_NSBackingLayer display] + 26
28 com.apple.AppKit 0x99b25b8a -[_NSViewBackingLayer display] + 552
29 com.apple.QuartzCore 0x9b2c77ad CA::Layer::display_if_needed(CA::Transaction*) + 667
30 com.apple.QuartzCore 0x9b2c6f30 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 38
31 com.apple.QuartzCore 0x9b2c64f2 CA::Context::commit_transaction(CA::Transaction*) + 284
32 com.apple.QuartzCore 0x9b2c612e CA::Transaction::commit() + 392
33 com.apple.QuartzCore 0x9b2d7807 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 75
34 com.apple.CoreFoundation 0x9b9bc43e CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 30
35 com.apple.CoreFoundation 0x9b9bc380 __CFRunLoopDoObservers + 400
36 com.apple.CoreFoundation 0x9b9ad6e1 CFRunLoopRunSpecific + 417
37 com.apple.CoreFoundation 0x9b9ad52b CFRunLoopRunInMode + 123
38 com.apple.HIToolbox 0x95a6e2d8 RunCurrentEventLoopInMode + 262
39 com.apple.HIToolbox 0x95a6dee3 ReceiveNextEventCommon + 192
40 com.apple.HIToolbox 0x95a6de0c _BlockUntilNextEventMatchingListInModeWithFilter + 99
41 com.apple.AppKit 0x99a13229 _DPSNextEvent + 734
42 com.apple.AppKit 0x99a12a71 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 186
43 com.xojo.XojoFramework 0x01a4692a 0x1a15000 + 203050
44 com.xojo.XojoFramework 0x01a46990 0x1a15000 + 203152
45 com.test.test 0x0003c9ba Delegate.Invoke%% + 34
46 com.test.test 0x000a48bc Application._CallFunctionWithExceptionHandling%%op + 248
47 com.xojo.XojoFramework 0x01b69cfa 0x1a15000 + 1395962
48 com.xojo.XojoFramework 0x01a468b9 0x1a15000 + 202937
49 com.apple.AppKit 0x99a0502c -[NSApplication run] + 907
50 com.xojo.XojoFramework 0x01b69d77 0x1a15000 + 1396087
51 com.xojo.XojoFramework 0x01b6832f RuntimeRun + 49
52 com.test.test 0x001c0197 REALbasic._RuntimeRun + 34
53 com.test.test 0x0003c8a6 _Main + 257
54 com.test.test 0x000027a4 main + 36
55 com.test.test 0x017668de start + 53

so the app loads ok and then just disappears and crash and i get that file.

Anybody having similar issues ?

Same code works perfect on RealBasic, and works also ok with same code on XOJO with different DB. Here i`m using a SQLite db , but i need to know from where is crashing.

Thanks.

Are you using any Declares?
It’s crashing somewhere near a Combo-box in a table.

Hello Tim,

The only declares that are in the project are in the FTUtilities (Formatted Text Control) from BKeeney.

Unfortunately there are a lot of tables and combo boxes so it does not say exactly where and what.

Thanks for the tip.

And there is an NSTableView.

If I had to guess, I’d say you have a ComboBox that has its completions loaded from the database. Does that sound feasible?

Hello Eli, there is no NSTableView from the search result .

Joe, i have something like 300 Combo Boxes so i guess i will have to take all of them one by one.

I`ll have a look on those.

Thanks for the tip.

There is not parser or something for those apple crash reports ? how does XOJO debug them ? or apple ?

Precisely symbolicating a crash report requires access to the symbol files, a dSYM bundle, created during the build. We don’t make ours public because they contain a large amount of information about how the runtime works internally. We’ve had problems in the past with third parties reverse engineering things to release unsafe products that depend on implementation details (which negatively affects our customers and provides us with compatibility headaches).

Your situation sounds somewhat similar to case #37871, which has been fixed for 2015r1. If you’re in the beta program, you can test this with the next beta.

The last called selector is CFStringCreateWithBytes.
The error is indicating an invalid address / released pointer.

Since you said, that you don’t use any declares, it happens probably within the Formatted Text Control. My guess is that something illegal is handed over to CFStringCreateWithBytes (for example a CString instead of a byte array).

I’m much more inclined to think that this is a framework bug. My guess would be it’s related to deleting rows from a ComboBox or to having strings with invalid encodings in the ComboBox (but that’s less likely).

Hello

I had the same message:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
After a lot of trials I found the solution:
I had an iOSImageView with PNG-File as Image.
The program couldn’t load this specific PNG-File.
With GraphicConverter I converted the PNG-File
to another PNG-File (for WEB : witout resources,
no EXIF) and now it works fine.

[quote=163873:@Stefan Cyrus]I had the same message:
Exception Type: EXC_BAD_ACCESS (SIGBUS)[/quote]

That crash is completely unrelated. EXC_BAD_ACCESS/SIGBUS cover basically any type of crash caused by memory corruption/mismanagement.

Well i taught to the same way but it seems that it not the case . The app crashes only after i change 2 databases, so i guess in the database that it crashes it has a missing file or field or something . on the good db it does not crash and does not generate that error , ive tested the memory and the drive and both passed on all the tests so im guessing its a framework issue something , somewhere . Unfortunately with limited debugging its a lot oh headache but what to do , in the end this is the fun of programming.

And i do understand and you are right of not sharing the data and the libs but if i could make a point here, just as an idea for the future, you could have like a handling server that does that only, you just upload the report via remote on it, similar to apple bug report portal and your server process the crash and give us the useful information without affecting security and avoid other issues.

Just an idea .

Thanks.

I would look closer at the database content - as Joe has already mentioned it might be related to the encoding of the queried data.