Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-24389] iOS: Appcelerator Titanium App Crashes after some usage time

GitHub Issuen/a
TypeBug
PriorityNone
StatusClosed
ResolutionNot Our Bug
Resolution Date2017-07-11T07:57:11.000+0000
Affected Version/sRelease 6.0.1
Fix Version/sRelease 6.0.3
ComponentsiOS
Labelsn/a
ReporterNeeraj Mishra
AssigneeVijay Singh
Created2017-02-09T05:03:20.000+0000
Updated2017-08-07T18:01:12.000+0000

Description

Problem Description:

Titanium App Crashes after some Camera usage time.

Steps to Reproduce:

- Use the attached app.js code in a classic app. tiapp.xml file is also attached. - Touch "open camera" - Take picture - Touch "Use Photo" - Repeat steps 30-35 times.

Actual Result

App crashes during the process of taking picture in above scenario.

Expected Results:

App should work usual and should not crash.

Some more details and question from customer:

Remarks: - iOS 10.2 camera permission is set - Happens once/twice a day. - Not directly/always reproducible - App closes and iOS springboard gets visible - Fabric.io is configured for crash reporting, but no crashes are captured (seems that Fabric doesn't get the chance to capture the crash). We couldn't get any logs of the issue due the fact production devices are not within reach. Question: is it possible that iOS kills the app because the camera screen (iOS app) takes a lot of memory/resources?

Attachments

FileDateSize
app.js2017-02-09T05:03:01.000+0000533
Bildschirmfoto 2017-02-24 um 11.40.12.png2017-02-24T15:38:37.000+000056442
Bildschirmfoto 2017-02-24 um 11.42.04.png2017-02-24T15:38:37.000+0000146660
InstrumentsLog24389.trace.zip2017-02-25T01:34:33.000+0000753535
SampleCameraApp.zip2017-06-15T08:07:50.000+000026952

Comments

  1. Hans Knöchel 2017-02-09

    I cannot see a crash-log, please attach. And did this also happen n earlier versions of the SDK (5.5.x)? If we have those infos, we can patch it for 6.0.2, thx!
  2. Neeraj Mishra 2017-02-10

    [~hansknoechel] : Attaching the crash log for the app I tested at my end. Also with couple of test with SDK 5.5.0 and CLI 5.5.0, i did not see any crash. I can't confirm it yet. I will check once more and post it here.
  3. Neeraj Mishra 2017-02-10

    crash log.
  4. Hans Knöchel 2017-02-10

    Here is the related crash-log: {quote} TCC, This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCameraUsageDescription key with a string value explaining to the user how the app uses this data. {quote} So either they didn't add the NSCameraUsageDescription key to the plist like noted in both the 5.5.0 and 6.0.0 release, or the crash comes from an invalid test-case to reproduce the issue.
  5. Eric Merriman 2017-02-13

    Made the ticket private.
  6. Abir Mukherjee 2017-02-14

    I was able to reproduce the issue. Here is the environment, and a description of what I did: NPM Version: 2.15.9 Node Version: 4.5.0 Mac OS: 10.12.1 Appc CLI: 6.1.0 Appc CLI NPM: 4.2.8 Titanium SDK version: 6.0.1. GA Appcelerator Studio, build: 4.8.1.201612050850 iOS Device: 10 I tested this by following the steps the reporter outlined. I clicked the button to take a picture, and the then clicked on the "Use Picture". After 35 times, the app crashed. The crashed occurred when clicking to take the picture.
  7. Neeraj Mishra 2017-02-21

    [~hansknoechel] : Do you have any updates on it?
  8. Neeraj Mishra 2017-02-22

    [~hansknoechel] : I have shared it over email.
  9. Hans Knöchel 2017-02-24

    I've fixed it. Tested with both main- and kroll-thread monitoring it with Instruments. The heap grows per image and is autoreleased a few seconds afterwards. I implemented an autorelease-pool around the sensitive core-image operation (the internal rotation of the image), retained the resulting image by the current context and released it after creating a blob from it. I also attached [two Instruments-traces](https://www.dropbox.com/s/h0jgv9pqr1hpqtt/OpenPhotoGallery-Traces.zip?dl=1) that show the leak (before) and the fix using the PR (afterwards), as well as some insights on the memory analysis. We could still include it in the 6.0.2.GA if the fix get's an approval before next Monday. [~emerriman] could your team test the issue today already? I know Vijay is on Holiday until Monday, so we could the fix in place before. Thx! PR: https://github.com/appcelerator/titanium_mobile/pull/8849 Test-Case (based on the one from the customer, modified to validate the fix by setting the image-view image as well): 
       var welcomeWindow = Ti.UI.createWindow({
       backgroundColor: '#fff'
   });
   
   var button = Ti.UI.createButton({ 
       title: 'Open Camera', 
       top: 50
   });
   
   var imgView = Ti.UI.createImageView();
   
   button.addEventListener('click', function() {
      // Change to "openPhotoGallery" to test gallery as well
      Ti.Media.showCamera({
           success: function(e) {
               imgView.image = null;
               imgView.image = e.media;
           },
           error: function() { },
           cancel: function() { },
           allowEditing: false,
           mediaTypes: [ Ti.Media.MEDIA_TYPE_PHOTO ]
       });
   });
   
   welcomeWindow.add(imgView);
   welcomeWindow.add(button);
   welcomeWindow.open();
  10. Abir Mukherjee 2017-02-25

    Using this environment: NPM Version: 2.15.9 Node Version: 4.5.0 Mac OS: 10.12.3 Appc CLI: 6.1.0 Appc CLI NPM: 4.2.8 Appcelerator Studio, build: 4.8.1.201612050850 iOS Device: 10.0 I did FR, and found that the app still crashes after 30 times when cycling between taking a picture and using picture. I tried this on main thread and also with jscore and in both cases the app crashes. I had Instruments running, and attached is the log "InstrumentsLog24389.trace.zip"
  11. Vijay Singh 2017-02-27

    [~hansknoechel] I verified the changes on main thread. In my case after 5-6 image memory get released and if I continue app get crashed after 16 more images . Instrument trace are https://www.dropbox.com/s/1quujgplkvjqs2g/Instruments_crash.trace.zip?dl=0 . Problem looks at core level. We have to dig out more for solution.
  12. Hans Knöchel 2017-02-27

    I can reproduce it again. The adjustRotation method is still causing it. I don't think it's on the core-level, because Kroll-objects are unaffected. The results from the CoreGraphics operations are causing it, as it can be seen in the Instruments details (see attached images). I tried releases the CGContext and CGImage manually, but a) this is done by UIGraphicsEndImageContext and b) calling it manually will crash the app. The issue is caused by the reference image (imgRef}) that doesn't get released, the actual result of the CG-operation is properly released. We need to check other solutions this week and I also want to create a native sample app to check the behavior there. Will ping back soon, thx!
  13. Vijay Singh 2017-02-27

    I have verified it by replacing line - 
         resultImage = [TiUtils adjustRotation:editedImage ?: originalImage];
    with
    resultImage = editedImage?:originalImage;
    This is also causing the same problem. So the problem is not with adjustRotation method. Checking behavior with native sample app is good idea.
  14. Vijay Singh 2017-03-01

    On basis of few points (mentioned below) 1.In case of KROLL THREAD due to below code snippet in KrollContext.m the heap is getting released early - if (loopCount == GC_LOOP_COUNT){ [self forceGarbageCollectNow]; } So heap do not grow much in this case. 2. In case of main thread, after reaching near crash point(e.g if crash is happening with 30 image, use 29 image), wait for approx. 10 mints (sometimes early). Heap will get release. 3. So similar to point 1 forceGarbageCollectNow called in mentioned PR, which will release heap early. PR :https://github.com/appcelerator/titanium_mobile/pull/8853
  15. Eric Wieber 2017-03-06

    I continue to get a crash after 22-26 picture takings when both main thread and jscore framework are true. If either are false, I do not encounter the crash. Also, as you say [~vijaysingh], if I wait just before the crash then the heap will be released and I can continue taking pictures after some time. The question is: Is this the intended and now expected behavior?
  16. Hans Knöchel 2017-03-07

    Please note that this fix is only for this ticket (the customers has main-thread, no JSCore enabled). For JSCore, we track TIMOB-24206.
  17. Eric Wieber 2017-03-07

    FR passed, using: MacOS 10.12 (16A323) Studio 4.8.1.201612050850 Ti SDK 6.1.0 Appc NPM 4.2.8 Appc CLI 6.1.0 Alloy 1.9.5 Xcode 8.2.1 (8C1002) Tested using the provided sample code by taking over 50 pictures in the app, built with main-thread enabled and disabled. No crash was encountered unless JScore was also enabled. This will be addressed by another ticket/PR. Verified in SDK 6.1.0.v20170307133328
  18. Eric Wieber 2017-03-07

    [~hansknoechel], [~vijaysingh]: Can we get a backport to 6_0_X or have the fixVersion updated accordingly?
  19. Vijay Singh 2017-03-08

    Backported PR : https://github.com/appcelerator/titanium_mobile/pull/8864 [~hansknoechel] Please review.
  20. Eric Wieber 2017-03-09

    Verified in SDKs 6.0.3.v20170309031327 and 6.1.0.v20170307133328
  21. Raymond Verbruggen 2017-05-29

    Sorry but this is the only way of asking; The issue has to to with NSCameraUsageDescription amongst others in a multi-language app. However I cannot file an issue in Jira... How can I add an issue to Jira TIMOB? I can only create an issue into the Aptana Studio part...
  22. Vijay Singh 2017-07-11

    Resolving this ticket as per comment by [~nmishra].
  23. Lee Morris 2017-08-07

    Closing ticket with reference to the previous comments.

JSON Source