Repository navigation
App crash on low memory notification with custom fonts (iOS only) #5019
Description
Using custom fonts in iOS apps cause the app to crash with a Segmentation Fault
For example:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
VM Region Info: 0x10 is not in any region. Bytes before following region: 4301701104
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 000000010066c000-0000000100670000 [ 16K] r-x/r-x SM=COW ...a.app/<Appname>]
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread: 13
where Thread 13 is handling the Dispatch queue: Internal _UICache queue.
To summarise that: This happens because the UIFontDescriptor used to obtain fonts in font.ios.ts#l144 ff somehow references memory that gets deallocated using WTF::StringWrapperCFAllocator::deallocate(void*,void*) on a low memory warning which then tries to call a block on the mainthread which is not possible in that situation (?).
Thread 13 Queue : Internal _UICache queue (serial)
#0 0x000000010fb8338c in pthread_mutex_lock ()
#1 0x000000010f492a5b in CFRunLoopPerformBlock ()
#2 0x000000010b9ad826 in WTF::StringWrapperCFAllocator::deallocate(void*, void*) ()
#3 0x000000010f455077 in CFRelease ()
#4 0x000000010f4642b5 in __CFBasicHashDrain ()
#5 0x000000010f454d0c in CFRelease ()
#6 0x0000000111003446 in TDescriptor::~TDescriptor() ()
#7 0x000000010f454d0c in CFRelease ()
#8 0x000000010fc7fa1b in -[_UIFontCacheKey dealloc] ()
#9 0x000000010ebb2afe in objc_object::sidetable_release(bool) ()
#10 0x000000010f4a0850 in -[__NSDictionaryM removeAllObjects] ()
#11 0x000000010c9653eb in _dispatch_client_callout ()
#12 0x000000010c949ef5 in _dispatch_barrier_sync_f_invoke ()
#13 0x000000010fca5f7c in __16-[_UICache init]_block_invoke ()
#14 0x000000010c9653eb in _dispatch_client_callout ()
#15 0x000000010c9587e5 in _dispatch_source_latch_and_call ()
#16 0x000000010c953770 in _dispatch_source_invoke ()
#17 0x000000010c94d996 in _dispatch_root_queue_drain ()
#18 0x000000010c94d405 in _dispatch_worker_thread3 ()
#19 0x000000010fb855a2 in _pthread_wqthread ()
#20 0x000000010fb8507d in start_wqthread ()
To reproduce:
- clone the following repository: https://github.com/Buuhuu/nativescript-5019
- prepare the app using
tns prepare ios - open it in xcode
open platform/ios/<projectfile>.xcodeproj - run the app using xcode on simulator (simulator can send low memory signals)
- In the simulators Debug menu simulate memory warning
- The app crashs with the stacktrace shown above
Versions and so on
- tns-core-modules 3.3.0 (in the example above), 3.1.1 (in our production app)
- tns-ios: 3.2.0
Unfortunately I was not able to change the creation of UIFontDescriptor to resolve the issue. For my project I patched font.ios.js but wasn't able to implement the UIFontWeightTrait ... anyway I want to share my implementation of l144 ff:
var fontNamesForFamilyName = UIFont.fontNamesForFamilyName(fontFamily); // NSArray<String>
for (var i = 0, c = fontNamesForFamilyName.count; i < c; i++) {
var fontCanidate = UIFont.fontWithNameSize(fontNamesForFamilyName.objectAtIndex(i), size);
if (fontCanidate.familyName !== fontFamily) {
continue;
}
// now apply the symbolic traits
if (symbolicTraits) {
var fontDescriptor = utils.ios.getter(fontCanidate, fontCanidate.fontDescriptor);
fontDescriptor = fontDescriptor.fontDescriptorWithSymbolicTraits(symbolicTraits);
fontCanidate = UIFont.fontWithDescriptorSize(fontDescriptor, size);
}
if (font.isItalic) {
var fontDescriptor = utils.ios.getter(fontCanidate, fontCanidate.fontDescriptor);
var actualItalic = fontDescriptor.symbolicTraits & 1;
if (!actualItalic && EMULATE_OBLIQUE) {
fontDescriptor = fontDescriptor.fontDescriptorWithMatrix(OBLIQUE_TRANSFORM);
fontCanidate = UIFont.fontWithDescriptorSize(fontDescriptor, size);
}
}
result = fontCanidate;
break;
}
if (result.familyName === fontFamily) {
break;
}
else {
result = null;
}
Activity
tsonevn commentedon Nov 1, 2017
Hi @buuhuu ,
Thank you for your interest in NativeScript.
Could you attach valid URL for the sample project? I tested the provided one, however, the repository seems to be empty. The sample project will help us to investigate further the issue.
Thank you in advance for your cooperation.
buuhuu commentedon Nov 1, 2017
@tsonevn apologise the empty repository please, but I had to go to lunch before I was able to push.
The repository (now after I pushed) is simply created from the hello world ng template where the only change was made in
app/app.cssto use the custom font for all Labels.davecoffin commentedon Nov 1, 2017
This is so bizarre, I've been experiencing this for weeks, finally came here to post an issue about it, and it was posted an hour ago. So....+1
buuhuu commentedon Nov 1, 2017
@davecoffin If you don't need the
font-weight(probably because you have different ttf's for different weights) I would really appreciate if you could test my change proposed. We are going to test it in our app more intensively but just to be really sure (those kind of crashs are quickly annoying for users and so the urgency of the issue is quite high)davecoffin commentedon Nov 1, 2017
@buuhuu Unfortunately weight is more important to me than the custom font, and this app is in testflight and the crashes are making all my coworkers 🙄 at me.
Ill disable custom fonts in my app, push a new version to testflight, then re-enable them and test your fix though.
davecoffin commentedon Nov 1, 2017
For what its worth though, I was using a font that has different files for every weight. Is that the problem? Do I need to specify the font file instead of the weight?
buuhuu commentedon Nov 1, 2017
Yes. Lets assume you have the FontARegular.ttf and FontABold.ttf. Instead of using
font-weight: boldfor the later one, you usefont-family: 'FontABold'instead offont-family: 'FontARegular'. This still crashs but with the fix from above (remember, no use offont-weightas I didn't manage to implement that) it should work.tsonevn commentedon Nov 1, 2017
Hi @buuhuu,
Thank you for the attached sample project. I tested it on my side while using latest ios-runtime CLI and modules 3.3.0, however, was unable to recreate the exact same error as the above described one.
I would suggest upgrading the NativeScript CLI to 3.3.0 while using the
npm install nativescript --gcommand and to change thetns-iosversion to 3.3.0 in your projectpackage.jsonfile.Then remove platforms and node_modules folders and rebuild the application. Let me know if you are able to recreate the same error after making those changes.
davecoffin commentedon Nov 1, 2017
I am running most recent. Here are the xcode crash logs, search for
2 NativeScript 0x00000001006a9b5c WTF::StringWrapperCFAllocator::deallocate(void*, void*) + 922017-10-30_17-34-00.4220_-0500-1eb8179b8956196a27d68f548fa68e3c1115f6dc.txt
buuhuu commentedon Nov 1, 2017
Indeed its not happening in tns-ios 3.3.0. Though that doesn't mean that it has been fixed, it might also mean that the crashing piece of code is not called in the sample project in case of a low memory warning. For me its almost impossible to figure that out, so can you test with 3.2.0?
I also have tons of those reports available, all showing the same for 3.1.0 and 3.2.0.
buuhuu commentedon Nov 2, 2017
@davecoffin can you debug the memory graph to find the outgoing references of _UIFontCacheKey instances, right after your app started? I didn't mange to get that due to missing knowledge on how to handle XCode. Anyway it would be interesting which of its outgoing references points to the WTF String.
davecoffin commentedon Nov 2, 2017
I honestly dont know how to do that either. But I am about to implement your fix, I removed the custom font with different files for different weights, so now its using the system font and setting that to bold. I am still using fontawesome font though, so I will let you know how it goes.
Frustratingly, I am not experiencing these crashes on emulator, iPhone 7 or an old iPad mini. Only other testflight users are, and I am getting the crash reports via Organizer in xcode.
davecoffin commentedon Nov 2, 2017
Ok so this is pretty random, but I was typing in font.ios to find the file in vscode, and look what file popped up! wtf.ts!!! Looks like its part of zone? I am kicking myself for using Angular for this app. As I see it right now my option is to downgrade zone, push an update to testflight, wait a day and see if there are crash reports 😡
buuhuu commentedon Nov 2, 2017
WTF namespace is not javascript, its c++ and part of WebKit
https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/text/cf/StringImplCF.cpp
For me the error is constantly reproducible with simulator using tns-ios 3.2.0. As I said between 3.2.0 and 3.3.0 there is no change that could explain me the resolution of the root cause - though I'm 99% sure that its in the block of js code mentioned.
39 remaining items
etabakov commentedon Nov 17, 2017
Yes, this is available since last week in @next. You can give it a try and let us know how it works for you.
prabudevarrajan1 commentedon Nov 20, 2017
@etabakov Yes, I used the @next and now there is no app crash due to memory warning. Thanks for fixing this issue.
etabakov commentedon Nov 20, 2017
Great, I'm closing the issue now. Feel free to open if the problem arises again.
davecoffin commentedon Dec 20, 2017
This still isnt in a release, and my app crashes have increased by 300% in production after releasing a minor bug fix update. I think this issue should remain open until this fix is deployed in an official release. What is the ETA? I prefer not to use @next on a production release, and I need to get these crashes fixed in my production app ASAP, like today.
etabakov commentedon Dec 20, 2017
Our current workflow is to close the issues as soon as a fix is available for the users, which is our @next release. I fully understand your concerns with using non production release and this fix will be part of the 3.4.0 release (as stated in the milestone tag), which is expected any minute now.
davecoffin commentedon Dec 20, 2017
Any minute is that literally true?
I get that the fix was available in @next, but this was a very difficult issue to diagnose, iOS applications crash seemingly at random. I would have hoped this would have been given a higher priority in a 3.3.x release and pushed out as soon as possible, there are likely tons of apps out there right now affected by this.
etabakov commentedon Dec 20, 2017
Literally :) It's available now. Let us know if it solves the issues you are experiencing.
davecoffin commentedon Dec 20, 2017
Thats great thanks. Are there release notes out yet?
etabakov commentedon Dec 20, 2017
The blog post with the latest changes is coming very soon on NativeScript's Blog. Stay tuned.
lock commentedon Aug 27, 2019
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.