I met an issue with wxWidgets 3.1.2 on GhostBSD 19.04 which is a FreeBSD with GNOME desktop. The build of my App looks OK but it crashed on
initializing globals. The same apps works OK on other Linux dists.
I've no idea so I tried the minimal example of wxWidgets. It crashed at the same point. I tried truss which is the equivalent of strace of F
reeBSD. Has anyone solved the same issue?
I used g++(g++ (FreeBSD Ports Collection) 8.3.0) to build wxWidgets. And it can not be debugged by gdb because it crashed at global init. Below is the call stack. Line 205 is the last line of minimal.cpp.
Core was generated by `./minimal'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000802a98a38 in vtable for __cxxabiv1::__si_class_type_info () from /lib/libcxxrt.so.1
(gdb) bt
#0 0x0000000802a98a38 in vtable for __cxxabiv1::__si_class_type_info () at /lib/libcxxrt.so.1
#1 0x0000000801a52006 in __dynamic_cast () at /usr/local/lib/gcc8/libstdc++.so.6
#2 0x0000000801ad0620 in bool std::has_facet<std::ctype<char> >(std::locale const&) () at /usr/local/lib/gcc8/libstdc++.so.6
#3 0x0000000801ac3cb4 in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale(std::locale const&) ()
at /usr/local/lib/gcc8/libstdc++.so.6
#4 0x0000000801ac4130 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) ()
at /usr/local/lib/gcc8/libstdc++.so.6
#5 0x0000000801a65a33 in std::ios_base::Init::Init() () at /usr/local/lib/gcc8/libstdc++.so.6
#6 0x000000000046ec5f in __static_initialization_and_destruction_0(int, int) (__initialize_p=1, __priority=65535)
at /usr/local/lib/gcc8/include/c++/iostream:74
#7 0x000000000046ee86 in _GLOBAL__sub_I_minimal.cpp(void) () at ./minimal.cpp:205
#8 0x0000000800aec3bd in () at /libexec/ld-elf.so.1
#9 0x0000000800b050b0 in () at /libexec/ld-elf.so.1
#10 0x0000000800b09000 in ()
#11 0x00007fffffffe710 in ()
#12 0x00007fffffffeaa2 in ()
#13 0x00007fffffffd830 in ()
#14 0x0000000800af7049 in () at /libexec/ld-elf.so.1
#15 0x00007fffffffd850 in ()
#16 0x0000000800aebf12 in () at /libexec/ld-elf.so.1
#17 0x0000000800b18a20 in ()
#18 0x00007fffffffe710 in ()
#19 0x0000000802ab0ce0 in ()
#20 0x0000000800b1fc00 in ()
#21 0x0000000800b18200 in ()
#22 0x00007fffffffe710 in ()
#23 0x00007fffffffd890 in ()
#24 0x0000000800af06ed in () at /libexec/ld-elf.so.1
#25 0x0000000800b181e0 in ()
#26 0x00007fffffffe710 in ()
SIGNAL 11 (SIGSEGV) code=SEGV_ACCERR trapno=12 by truss
Related
I've disassembled a stripped ARM binary with Hopper and found the address of a method I'm interested in, 0x00065414. However, when connecting to the running app with gdb all addresses start from a base address that I cannot figure out. How can I determine my running applications base address (Entry Point?) in gdb?
Notes
The binary's FairPlay DRM was removed using Clutch
ASLR was removed by clearing the PIE header flag using a python script
Verified changes using otool
GDB setup
$ gdb ./MyApplication
(gdb) attach -waitfor MyApplication
Start App and it pauses immediately at launch.
(gdb) where
#0 0x3bbcdb88 in <redacted> ()
#1 0x3bbbc8fc in <redacted> ()
#2 0x3bbc4130 in <redacted> ()
#3 0x3bbc4014 in ccpbkdf2_hmac ()
#4 0x3bb9f9d0 in CCKeyDerivationPBKDF ()
#5 0x0015b750 in dyld_stub_pthread_key_create ()
#6 0x0015ca46 in dyld_stub_pthread_key_create ()
#7 0x0015c69c in dyld_stub_pthread_key_create ()
#8 0x0015b4d0 in dyld_stub_pthread_key_create ()
#9 0x0015c110 in dyld_stub_pthread_key_create ()
#10 0x0001695a in dyld_stub_pthread_key_create ()
#11 0x000ba256 in dyld_stub_pthread_key_create ()
#12 0x00017bde in dyld_stub_pthread_key_create ()
#13 0x33b9eaac in <redacted> ()
#14 0x33b9e4f2 in <redacted> ()
#15 0x33b98b40 in <redacted> ()
#16 0x33b33a06 in <redacted> ()
#17 0x33b32cfc in <redacted> ()
#18 0x33b98320 in <redacted> ()
#19 0x3601876c in <redacted> ()
#20 0x36018356 in <redacted> ()
#21 0x31374776 in <redacted> ()
#22 0x31374712 in <redacted> ()
#23 0x31372ede in <redacted> ()
#24 0x312dd470 in CFRunLoopRunSpecific ()
#25 0x312dd252 in CFRunLoopRunInMode ()
#26 0x33b975c2 in <redacted> ()
#27 0x33b92844 in UIApplicationMain ()
#28 0x0001aaf2 in dyld_stub_pthread_key_create ()
#29 0x00009028 in dyld_stub_pthread_key_create ()
Checking various locations for expected instructions so I can set a breakpoint:
(gdb) disas 0x65414
No function contains specified address.
I assume that the correct location is some + 0x65414. So I tried 0x33b92844 which is UIApplicationMain as the base.
(gdb) disas 0x33BF7C58
Dump of assembler code for function <redacted>:
0x33bf7934 <<redacted>+0>: f0 b5 push {r4, r5, r6, r7, lr}
This address is definitely in the land of redacted or symbol stripped code, but the address doesn't land you on a procedure boundary. So it isn't the right place.
You can try a :
starti
It let you enter in your dynamic linker (if your binary id dynamically linked) which will call the __libc_start_main function and as argument of this function, it gives a pointer toward the main function. So you have to set a breakpoint on this address (b*<addr_of_main>) and to continue the execution by using the continue command.
Now that your are in the main function, wait that your programm call your method, if you can't enter in this function, you can modify your registers with :
set $<register>=<value>
Your binary might be loaded with ASLR which is a security feature to make addresses to code and data unpredictable.
Try disabling ASLR when you're in GDB - before loading the executable.
(gdb) set disable-randomization off
(gdb) start
Use info file and/or info shared to figure out the executable's load address or the actual entrypoint address.
(gdb) info file
Mac OS X executable:
<...>/test, file type mach-o-le.
Entry point: 0x00002104
0x00001000 - 0x0002b000 is <...>/test
<...>
Our ios application crashes when a UITextField with default type is touched.
There is another uitextfield which is numpad and it works okay.
The crash only occurs on ios 5.0.1 and ios 4.x works okay.
The UITextField is created with interface builder and I didn't add any delegates for it.
The project was created on 4.0.2 and I also tested the same project on 4.2.
If I create a new project and just put a UITextField in it there is no problem.
Somehow something in my project causes the UITextField to crash and I don't have any idea how to debug it.
The crash log is like following:
(gdb) bt
#0 0x33fa2fdc in CFRetain ()
#1 0x37991db6 in ___init_block_invoke_2 ()
#2 0x36c8e7ea in _dispatch_barrier_sync_f_invoke ()
#3 0x36c8e65a in dispatch_barrier_sync_f$VARIANT$up ()
#4 0x36c8e28e in dispatch_sync_f$VARIANT$up ()
#5 0x36c8e910 in dispatch_sync$VARIANT$up ()
#6 0x36c90576 in dispatch_once_f$VARIANT$up ()
#7 0x37992706 in CPLoggingAddCustomLogFile ()
#8 0x306ee658 in __MCLoggingInitialize_block_invoke_1 ()
#9 0x36c90576 in dispatch_once_f$VARIANT$up ()
#10 0x306ee6a4 in MCLoggingInitialize ()
#11 0x306ef060 in -[MCProfileConnection _init] ()
#12 0x306ef764 in +[MCProfileConnection sharedConnection] ()
#13 0x31758cce in _FTAreIDsEquivalent ()
#14 0x31758a46 in _FTAreIDsEquivalent ()
#15 0x317589c8 in _FTAreIDsEquivalent ()
#16 0x36c90576 in dispatch_once_f$VARIANT$up ()
#17 0x31758976 in _FTAreIDsEquivalent ()
#18 0x35026378 in GCC_except_table11 ()
#19 0x3504571c in _NSStringDescriptionForIMAVChatParticipantState ()
#20 0x350456a8 in _NSStringDescriptionForIMAVChatParticipantState ()
#21 0x36c90576 in dispatch_once_f$VARIANT$up ()
#22 0x35045656 in _NSStringDescriptionForIMAVChatParticipantState ()
#23 0x377931e2 in -[UIDictationController init] ()
#24 0x37793350 in +[UIDictationController sharedInstance] ()
#25 0x37793590 in +[UIDictationController fetchCurrentInputModeSupportsDictation] ()
#26 0x376b21d0 in -[UIKeyboardLayoutStar shouldShowDictationKey] ()
#27 0x374f4138 in -[UIKeyboardLayoutStar updateMoreAndInternationalKeys] ()
#28 0x374f206e in -[UIKeyboardLayoutStar setKeyplaneName:] ()
#29 0x374f0e62 in -[UIKeyboardLayoutStar showKeyboardType:appearance:orientation:withShift:] ()
#30 0x37481bc4 in -[UIKeyboardImpl updateLayout] ()
#31 0x37425f6a in -[UIKeyboardImpl setDelegate:force:] ()
#32 0x37407f22 in -[UIPeripheralHost(UIKitInternal) _reloadInputViewsForResponder:] ()
#33 0x37407c6e in -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] ()
#34 0x374077aa in -[UIResponder becomeFirstResponder] ()
#35 0x37505d76 in -[UITextInteractionAssistant setFirstResponderIfNecessary] ()
#36 0x37505640 in -[UITextInteractionAssistant oneFingerTap:] ()
#37 0x37504f06 in _UIGestureRecognizerSendActions ()
#38 0x37496c1c in -[UIGestureRecognizer _updateGestureWithEvent:] ()
#39 0x376c2508 in ___UIGestureRecognizerUpdate_block_invoke_0541 ()
#40 0x37411d68 in _UIGestureRecognizerApplyBlocksToArray ()
#41 0x374108b6 in _UIGestureRecognizerUpdate ()
#42 0x3741d3cc in _UIGestureRecognizerUpdateGesturesFromSendEvent ()
#43 0x3741d20e in -[UIWindow _sendGesturesForEvent:] ()
#44 0x3741cddc in -[UIWindow sendEvent:] ()
#45 0x374034ec in -[UIApplication sendEvent:] ()
#46 0x37402d2c in _UIApplicationHandleEvent ()
#47 0x30835df2 in PurpleEventCallback ()
#48 0x3402e552 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#49 0x3402e4f4 in __CFRunLoopDoSource1 ()
#50 0x3402d342 in __CFRunLoopRun ()
#51 0x33fb04dc in CFRunLoopRunSpecific ()
#52 0x33fb03a4 in CFRunLoopRunInMode ()
#53 0x30834fcc in GSEventRunModal ()
#54 0x37431742 in UIApplicationMain ()
#55 0x00002462 in main (argc=1, argv=0x2fdffb04) at /Users/xxxx/Desktop/ios5/
Change "Product Name"
I had exactly same problem. I've solved it with changing "Product Name" property on build settings of target. Looks like having Non-USA characters, special characters like "ü, ğ, ç" etc. masses up your application.
I've absolutely no idea why this creates a problem such. But making product name something like "Ocu" instead of "Öcü" fixes it.
I found about this information on another question's answer and here is the link.
Make sure in interface builder that the UITextField does not have any current outlets. It's a common mishap to duplicate existing UITextFields and not realize that they were previously linked to other outlets or making references to things that are no longer there.
I'm getting an EXC_BAD_ACCESS (or a malloc error) on the following line of code:
NSLog(#"Points:");
Which makes zero sense to me, as it should be accessing a string constant and nothing else. It's usually an EXC_BAD_ACCESS, but it occasionally is the following error (on the same line):
Annotate23D(50572,0xac6bb2c0) malloc: *** error for object 0x7051004: incorrect checksum for freed object - object was probably modified after being freed.
The stack trace for the malloc error (I'm having a hard time getting a full one out of the bad access error) is:
#0 0x960e7c97 in malloc_error_break ()
#1 0x960a94ce in szone_error ()
#2 0x960a954e in free_list_checksum_botch ()
#3 0x960afec0 in small_malloc_from_free_list ()
#4 0x960b124c in szone_malloc_should_clear ()
#5 0x960b166b in szone_malloc ()
#6 0x960e7962 in malloc_zone_malloc ()
#7 0x960e8882 in malloc ()
#8 0x020e5837 in uhash_hashUChars ()
#9 0x020e5c01 in uhash_setResizePolicy ()
#10 0x020e5ca5 in uhash_init ()
#11 0x02075896 in uhash_open ()
#12 0x021f5978 in icu::ZoneMeta::getCanonicalCLDRID ()
#13 0x021f6a4f in icu::ZoneMeta::getCanonicalCLDRID ()
#14 0x021ab551 in icu::TimeZone::getCanonicalID ()
#15 0x021bfaf2 in ucal_getCanonicalTimeZoneID ()
#16 0x024d8bf4 in __nameStringOK ()
#17 0x024d8ae4 in -[__NSPlaceholderTimeZone __initWithName:cache:] ()
#18 0x024d89d0 in -[__NSPlaceholderTimeZone initWithName:] ()
#19 0x024d884b in +[NSTimeZone timeZoneWithName:] ()
#20 0x024d8768 in +[NSTimeZone systemTimeZone] ()
#21 0x024d84d7 in +[NSTimeZone defaultTimeZone] ()
#22 0x024d846d in CFTimeZoneCopyDefault ()
#23 0x024e6726 in CFCalendarCreateWithIdentifier ()
#24 0x02509e67 in __CFLogCString ()
#25 0x02509db3 in _CFLogvEx ()
#26 0x00b99b63 in NSLogv ()
#27 0x00b99ad5 in NSLog ()
#28 0x00008323 in -[Cylinderoid generateMesh] (self=0x6a73fa0, _cmd=0x6e836) at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/Cylinderoid.mm:154
#29 0x0006cd85 in -[MeshGenerator rendererForObjects:] (self=0x6a67b80, _cmd=0x6e246, workspace=0xa83f270) at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/MeshGenerator.m:16
#30 0x00005367 in -[WorkspaceViewController renderButton:] (self=0xa8377f0, _cmd=0x6e4ac, sender=0x6a58260) at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/WorkspaceViewController.m:304
#31 0x02562ec9 in -[NSObject performSelector:withObject:withObject:] ()
#32 0x002365c2 in -[UIApplication sendAction:to:from:forEvent:] ()
#33 0x0023655a in -[UIApplication sendAction:toTarget:fromSender:forEvent:] ()
#34 0x002dbb76 in -[UIControl sendAction:to:forEvent:] ()
#35 0x002dc03f in -[UIControl(Internal) _sendActionsForEvents:withEvent:] ()
#36 0x002db2fe in -[UIControl touchesEnded:withEvent:] ()
#37 0x004f4a2a in _UIGestureRecognizerUpdate ()
#38 0x025359ce in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#39 0x024cc670 in __CFRunLoopDoObservers ()
#40 0x024984f6 in __CFRunLoopRun ()
#41 0x02497db4 in CFRunLoopRunSpecific ()
#42 0x02497ccb in CFRunLoopRunInMode ()
#43 0x0244a879 in GSEventRunModal ()
#44 0x0244a93e in GSEventRun ()
#45 0x00233a9b in UIApplicationMain ()
#46 0x00002b88 in main (argc=1, argv=0xbffff590) at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/main.m:1
It may be relevant that the file in question is an Objective-C++ file with ARC turned on. The method itself is huge, so I put it up here to keep the question shortish. The line in question is line 94. Any ideas on either how to fix it or how to debug are greatly appreciated. Thanks in advance!
Quick edit:
I'm now also getting page corruption errors. From the debugger:
Annotate23D(50697) malloc: protecting edges
Annotate23D(50697) malloc: recording malloc stacks to disk using standard recorder
Annotate23D(50697) malloc: process 50678 no longer exists, stack logs deleted from /tmp/stack-logs.50678.Annotate23D.QDMh8a.index
Annotate23D(50697) malloc: stack logs being written into /tmp/stack-logs.50697.Annotate23D.XuPnEH.index
objc[50697]: autorelease pool page 0x7239000 corrupted
magic 0 3f473a55 3f20c2f1 0
pthread 0x43af3ce7
(gdb) bt
#0 0x026f28e5 in _objc_trap ()
#1 0x026f296e in _objc_fatal ()
#2 0x02706960 in objc_autoreleasePoolPush ()
#3 0x0248a95a in _CFAutoreleasePoolPush ()
#4 0x00b24e2b in NSPushAutoreleasePool ()
#5 0x00b99af4 in NSLogv ()
#6 0x00b99ad5 in NSLog ()
#7 0x00008323 in -[Cylinderoid generateMesh] (self=0x6ddd8a0, _cmd=0x6e836) at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/Cylinderoid.mm:151
#8 0x0006cd85 in -[MeshGenerator rendererForObjects:] (self=0x6a9de30, _cmd=0x6e246, workspace=0x6dc1460) at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/MeshGenerator.m:16
#9 0x00005367 in -[WorkspaceViewController renderButton:] (self=0x6db8a30, _cmd=0x6e4ac, sender=0x6dbd6a0) at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/WorkspaceViewController.m:304
#10 0x02562ec9 in -[NSObject performSelector:withObject:withObject:] ()
#11 0x002365c2 in -[UIApplication sendAction:to:from:forEvent:] ()
#12 0x0023655a in -[UIApplication sendAction:toTarget:fromSender:forEvent:] ()
#13 0x002dbb76 in -[UIControl sendAction:to:forEvent:] ()
#14 0x002dc03f in -[UIControl(Internal) _sendActionsForEvents:withEvent:] ()
#15 0x002db2fe in -[UIControl touchesEnded:withEvent:] ()
#16 0x004f4a2a in _UIGestureRecognizerUpdate ()
#17 0x025359ce in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#18 0x024cc670 in __CFRunLoopDoObservers ()
#19 0x024984f6 in __CFRunLoopRun ()
#20 0x02497db4 in CFRunLoopRunSpecific ()
#21 0x02497ccb in CFRunLoopRunInMode ()
#22 0x0244a879 in GSEventRunModal ()
#23 0x0244a93e in GSEventRun ()
#24 0x00233a9b in UIApplicationMain ()
#25 0x00002b88 in main (argc=1, argv=0xbffff590) at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/main.m:16
(gdb) info malloc-history 0x7239000
Alloc: Block address: 0x07239000 length: 4096
Stack - pthread: 0xac6bb2c0 number of frames: 4
0: 0x960e76ee in malloc_zone_memalign
1: 0x270697d in objc_autoreleasePoolPush
2: 0x2b22 in main at /Users/haldean/Code/ipad/Annotate23D/Annotate23D/main.m:16
3: 0x2ae5 in start
Old question but in Swift you'll get this issue if you are logging an encoded URL which contains '%' - For example:
NSLog("My long Encoded URL: \(myLongUrlVar)")
Instead, it will work with params:
NSLog("My long Encoded URL: %#", myLongUrlVar)
In the comments I suggested:
The problem is not with NSLog. The problem is probably that some memory is getting smashed and that is causing the crash in NSLog. It would probably help if you could break down that method you're using to make it easier to read, perhaps even separating the functionality into a new object. Also, avoid the use of magic numbers (3 & 6).
It appears that #haldean went with this suggestion and tracked down the problem. I can't claim credit for actually doing the hard work of tracking down the problem, but I'm happy the suggestion helped.
there are % in string, replace % to %%
NSLog([message stringByReplacingOccurrencesOfString:#"%" withString:#"%%"]);
First thing I would try (after zombie hunting or perhaps before in this case) is to clear out the build directories and do a fresh rebuild. Sometimes left over cruft from prior builds can cause strange problems.
Usually, when I try to fix a BAD_ACCESS error I open the Xcode Instruments and test to find the zombies that are causing the error.
I'm running my app with iPhone 5.0 simulator. It stops with BAD_ACCESS, but Instruments doesn't flags any zombie.
The behavior is totally different when I run the app with iPhone 4.3 simulator. In this case, the application runs very well without any BAD_ACCESS.
I'm using XCode 4.2.
What could be happening?
Here's the backtrace:
(gdb) bt
#0 0x0167209b in objc_msgSend ()
#1 0x00002ff2 in -[BSViewController viewDidAppear:] (self=0x1, _cmd=0x12ddd81, animated=1 '\001') at BSViewController.m:42
#2 0x012616f8 in __CFStringAppendFormatCore ()
#3 0x011acb6c in _CFStringCreateWithFormatAndArgumentsAux ()
#4 0x0122bce8 in _CFLogvEx ()
#5 0x00b26b63 in NSLogv ()
#6 0x00b26ad5 in NSLog ()
#7 0x00009ffc in -[BSCTView buildFrames] (self=0x6a55f80, _cmd=0xd541) at BSCTView.m:96
#8 0x0000a5da in -[BSCTView layoutSubviews] (self=0x6a55f80, _cmd=0x66a6c4) at BSCTView.m:124
#9 0x001ff301 in -[UIView(CALayerDelegate) layoutSublayersOfLayer:] ()
#10 0x01284e72 in -[NSObject performSelector:withObject:] ()
#11 0x0283592d in -[CALayer layoutSublayers] ()
#12 0x0283f827 in CA::Layer::layout_if_needed ()
#13 0x027c5fa7 in CA::Context::commit_transaction ()
#14 0x027c7ea6 in CA::Transaction::commit ()
#15 0x0285330c in +[CATransaction flush] ()
#16 0x001bf4c6 in -[UIApplication _reportAppLaunchFinished] ()
#17 0x001bfbd6 in -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] ()
#18 0x001ce743 in -[UIApplication handleEvent:withNewEvent:] ()
#19 0x001cf1f8 in -[UIApplication sendEvent:] ()
#20 0x001c2aa9 in _UIApplicationHandleEvent ()
#21 0x01748fa9 in PurpleEventCallback ()
#22 0x012571c5 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#23 0x011bc022 in __CFRunLoopDoSource1 ()
#24 0x011ba90a in __CFRunLoopRun ()
#25 0x011b9db4 in CFRunLoopRunSpecific ()
#26 0x011b9ccb in CFRunLoopRunInMode ()
#27 0x001bf2a7 in -[UIApplication _run] ()
#28 0x001c0a9b in UIApplicationMain ()
#29 0x000027a0 in main (argc=1, argv=0xbffff578) at main.m:16
As said above by #AdamRosenfield, on question comments, EXC_BAD_ACCESS can be caused by many other things that aren't zombies.
In this specific case, the problem was an NSLog() with a format string that expected an object #"%#" and was receiving an int as a parameter, as the example bellow.
int variable = 1;
NSLog(#"%#", variable);
This was causing the EXC_BAD_ACCESS.
After reading the backtrace, I saw that line #6 and searched all NSLog() calls on code to finally found the one with error.
My iPad app hangs on startup sometimes. It looks like the main thread is getting deadlocked with another thread but not sure why. Any ideas on what's causing this and how to debug this?
FYI my app starts as a splitview controller with a listview on the left and a webview on the right. If I start in portrait mode with the list view hidden the problem doesn't occur. Also, if I disable renderig of my cell when not on the main thread the app doesn't hang but the cells appear as black rectangles.
Thanks!
Here's my main thread. All of the code on this stack is Apple framework...
#0 0x971c0142 in semaphore_wait_signal_trap ()
#1 0x971c5c06 in pthread_mutex_lock ()
#2 0x02685903 in CGFontCacheLock ()
#3 0x02685869 in CGGlyphLockLockGlyphBitmaps ()
#4 0x0a90bb5b in ripc_RenderGlyphs ()
#5 0x0a9199f8 in ripc_DrawGlyphs ()
#6 0x0268464c in draw_glyphs ()
#7 0x02683e97 in CGContextShowGlyphsWithAdvances ()
#8 0x035aafba in WebCore::Font::drawGlyphs ()
#9 0x035aaaf5 in WebCore::Font::drawGlyphBuffer ()
#10 0x035aa81a in WebCore::Font::drawSimpleText ()
#11 0x035aa4c0 in drawAtPoint ()
#12 0x035a9d5c in -[NSString(WebStringDrawing) _web_drawAtPoint:forWidth:withFont:ellipsis:letterSpacing:includeEmoji:] ()
#13 0x0043f632 in -[NSString(UIStringDrawing) drawAtPoint:forWidth:withFont:lineBreakMode:letterSpacing:includeEmoji:] ()
#14 0x0043f325 in -[NSString(UIStringDrawing) drawAtPoint:forWidth:withFont:lineBreakMode:] ()
#15 0x0055ba70 in -[UILabel _drawTextInRect:baselineCalculationOnly:] ()
#16 0x00559178 in -[UILabel drawTextInRect:] ()
#17 0x0045418f in -[UIView(CALayerDelegate) drawLayer:inContext:] ()
#18 0x02a708d2 in -[CALayer drawInContext:] ()
#19 0x02a704b0 in backing_callback ()
#20 0x02a6fd52 in CABackingStoreUpdate ()
#21 0x02a6f01d in -[CALayer _display] ()
#22 0x02a6eac7 in CALayerDisplayIfNeeded ()
#23 0x02a609e1 in CA::Context::commit_transaction ()
#24 0x02a60732 in CA::Transaction::commit ()
#25 0x00427556 in -[UIApplication _reportAppLaunchFinished] ()
#26 0x0042dd3e in -[UIApplication handleEvent:withNewEvent:] ()
#27 0x004294f7 in -[UIApplication sendEvent:] ()
#28 0x004311d8 in _UIApplicationHandleEvent ()
#29 0x033f817c in PurpleEventCallback ()
#30 0x02bec89c in CFRunLoopRunSpecific ()
#31 0x02beb8a8 in CFRunLoopRunInMode ()
#32 0x00427221 in -[UIApplication _run] ()
#33 0x0042f372 in UIApplicationMain ()
And another thread rendering a cell in my list view. MyFancyPantsCell & ABTableViewCellView are my classes.
#0 0x971c0142 in semaphore_wait_signal_trap ()
#1 0x971c5c06 in pthread_mutex_lock ()
#2 0x02685903 in CGFontCacheLock ()
#3 0x02685869 in CGGlyphLockLockGlyphBitmaps ()
#4 0x0a90bb5b in ripc_RenderGlyphs ()
#5 0x0a9199f8 in ripc_DrawGlyphs ()
#6 0x0268464c in draw_glyphs ()
#7 0x02683e97 in CGContextShowGlyphsWithAdvances ()
#8 0x035aafba in WebCore::Font::drawGlyphs ()
#9 0x035aaaf5 in WebCore::Font::drawGlyphBuffer ()
#10 0x035aa81a in WebCore::Font::drawSimpleText ()
#11 0x035aa4c0 in drawAtPoint ()
#12 0x035a9d5c in -[NSString(WebStringDrawing) _web_drawAtPoint:forWidth:withFont:ellipsis:letterSpacing:includeEmoji:] ()
#13 0x0043f632 in -[NSString(UIStringDrawing) drawAtPoint:forWidth:withFont:lineBreakMode:letterSpacing:includeEmoji:] ()
#14 0x0043f381 in -[NSString(UIStringDrawing) drawAtPoint:withFont:] ()
#15 0x000635ec in -[SymbolCellPainter drawContentView:selected:editing:frame:]
#16 0x000452d0 in -[MyFancyPantsCell drawContentView:]
#17 0x00044624 in -[ABTableViewCellView drawRect:]
#18 0x0045418f in -[UIView(CALayerDelegate) drawLayer:inContext:] ()
#19 0x02a708d2 in -[CALayer drawInContext:] ()
#20 0x02a704b0 in backing_callback ()
#21 0x02a6fd52 in CABackingStoreUpdate ()
#22 0x02a6f01d in -[CALayer _display] ()
#23 0x02a6eac7 in CALayerDisplayIfNeeded ()
#24 0x02a609e1 in CA::Context::commit_transaction ()
#25 0x02a60732 in CA::Transaction::commit ()
#26 0x02a9e04f in CA::Transaction::release_thread ()
#27 0x971f61e3 in _pthread_tsd_cleanup ()
#28 0x971f5df6 in _pthread_exit ()
#29 0x00183bf2 in +[NSThread exit] ()
#30 0x00183b5b in __NSThread__main__ ()
#31 0x971ed81d in _pthread_start ()
#32 0x971ed6a2 in thread_start ()
I looks like you've created another thread, e.g. via [object performSelectorInBackground:#selector(foo) withObject:bar]. And in that thread you call GUI methods. You should call the GUI methods with [object performSelectorOnMainThread:#selector(alpha) withObject:beta waitUntilDone:YES] (maybe create another method that just contains the GUI methods and call that one this way instead of doing 20 performSelectorOnMainThreads).
All GUI methods should run on the main thread.
Are you using CATransitions somewhere in your code ?
Core Animation supports two types of transactions: implicit transactions and explicit transactions. Implicit transactions are created automatically when the layer tree is modified by a thread without an active transaction and are committed automatically when the thread's run-loop next iterates. Explicit transactions occur when the the application sends the CATransaction class a begin message before modifying the layer tree, and a commit message afterwards.
It seems that implicit transactions can fire in background threads calling drawRect from there.
If there's some drawing going on in the main thread at the same time - you're in trouble.
In this case, [CATransaction begin] / [CATransaction commit] MAY help.