[TIMOB-20296] iOS - KrollObject forgetKeylessKrollObject
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Cannot Reproduce |
Resolution Date | 2019-11-19T22:14:24.000+0000 |
Affected Version/s | Backlog |
Fix Version/s | n/a |
Components | iOS |
Labels | ios, iphone |
Reporter | Soumya Kanti Kar |
Assignee | Unknown |
Created | 2016-01-29T17:59:56.000+0000 |
Updated | 2019-11-19T22:14:24.000+0000 |
Description
Recently we have received a crash on one of our application with the following stack trace:
0 libobjc.A.dylib 0x00000001806c1bd0 objc_msgSend + 12
1 CoreFoundation 0x0000000180f72d90 -[NSInvocation retainArguments] + 208
2 Foundation 0x00000001819e86b4 -[NSInvocationOperation initWithInvocation:] + 72
3 Foundation 0x00000001819e85c8 -[NSInvocationOperation initWithTarget:selector:object:] + 216
4 MyApp 0x0000000100054500 -[KrollObject forgetKeylessKrollObject:] (KrollObject.m:1079)
5 MyApp 0x00000001000a1cac -[TiProxy forgetProxy:] (TiProxy.m:725)
6 MyApp 0x000000010005b070 -[TiViewProxy remove:] (TiViewProxy.m:261)
7 MyApp 0x00000001000ba294 __TiThreadPerformOnMainThread_block_invoke (TiBase.m:270)
8 MyApp 0x00000001000ba570 TiThreadProcessPendingMainThreadBlocks (TiBase.m:367)
9 libdispatch.dylib 0x0000000180a95630 _dispatch_call_block_and_release + 20
10 libdispatch.dylib 0x0000000180a955f0 _dispatch_client_callout + 12
11 libdispatch.dylib 0x0000000180a9acf8 _dispatch_main_queue_callback_4CF + 1840
12 CoreFoundation 0x0000000180ff8bb0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
13 CoreFoundation 0x0000000180ff6a18 __CFRunLoopRun + 1624
14 CoreFoundation 0x0000000180f25680 CFRunLoopRunSpecific + 380
15 GraphicsServices 0x0000000182434088 GSEventRunModal + 176
16 UIKit 0x0000000185d9cd90 UIApplicationMain + 200
17 MyApp 0x000000010003c584 main (main.m:37)
Dashboard suggests that the crash has happened at forgetKeylessKrollObjject method. From the stack trace it seems that during a view removal, this incident happened. There are many places in the code where we have added and removed view. As there is no definite place defined in the log and nor we have the test case, we went through the framework code and saw that there is no null handling inside the method as TiProxy.m --> krollObjectForBridge function can return nil.
Again, in the javascript code, if we do something like:
window.remove(null);
We too can see that TiViewProxy remove is called, but the application does not crash due to ENSURE_ARGS check I guess. Hence does it mean that the issue is occurring due to scenario where the UI has been garbage collected but not set to null for which it is trying to clean it.
Also this issue does not occur everyday, rather 3-5 times a week across several iOS devices with majorly running iOS 9. We do not have a test case, we only get the same stack trace from the dashboard.
Hello, Window "remove" method has to have a view in it to remove from the window. Looks like your project was developed in a much older SDK and xcode versions. This might be the reason for occasional crash on devices running latest OS iOS 9.0. It will be wise to develop a version 2.0 of the application with latest SDKs. Thanks.
Yes, we agree that the application is required to be updated to the latest Appcelerator SDK (5.1.2.GA at the moment) and built using the latest XCode 7.x. The reason for raising the JIRA is to check as to how and when this exception can occur. Also, we are aware that window remove API will accept UIView object, but the purpose of passing NULL was to confirm that the SDK can handle null scenario and it did not crash. It is confirmed that even if we pass NULL, the application did not crash (release mode), but the same remove API caused the crash (in release mode in production), which means that the application did not pass null, rather a UIView object, which somehow seems to be already removed. (may be a timing issue?)
I get something similar with a 3rd party module. After using quite a lot of memory, memory warnings are thrown and eventually the app crashes here:
with this error:
what's happening exactly?
[~soumyakantikar] It should not handle null-elements, that's why the check it there. If it passes that check, it may be non-null but the address of the passed reference has already been GC'd (usually when you remove an element from an external / invalid scope). But if you can provide a test-case (which is hard), then it should be an easy one. [~a.marcone] Probably the module has some leaks causing the same thing as above to happen. Always retain and release property and take care of retain cycles. And the error looks like you are trying to return a value that isn't bridged. For example, bridge native classes to either proxies or dictionaries. In your case, you want to return a
CFBooleanRef
without casting it to a numeric boolean in theNSNumber
pool.I'm seeing this crash in the Performance dashboard with our app as well. Environment: Ti SDK 6.0.1.GA, Xcode 8.2.1, iOS various 10.x versions and various iOS devices. I can't be sure, but I don't recall seeing this error prior to 6.x and ios 10.x. So, this might be a regression or some iOS change that is now causing issues.
Looking again at the crashlogs, the oldest of this crash I see is dated Oct 25th, 2016. Our app was using 5.5.1.GA with that particular release.
Closing issue as “Cannot Reproduce”. No test code provided, or code provided in URL links is no longer available. The SDKs listed are out of date with our current release (8.2.1.GA as of the date of closure), and out of date with mobile OS versions. However, a significant number of crash-related issues have been addressed in SDK 7.4.x. If community members feel that the issue is still valid, please add a comment, and include code that demonstrates/reproduces the issue.