Status-react: Crash on IOS after adding access to photos in case of heavy images (>10 MB)

Created on 16 Jul 2020  ·  12Comments  ·  Source: status-im/status-react

Bug Report

Problem

Currently on my device (IPhone7, IOS 13.5.1) I'm not able to send photos - after getting access to library and display of 2 photos app is crashed.
It happens when app has some heavy photos (i.e. panoramas) and try to preview them in-app.
Reproducible on 1.4.1 (when images are enabled)

Expected behavior

no crash

Actual behavior

app is crashed

ezgif com-video-to-gif (6)

Reproduction

  • Open Status
  • Make several heavy photos (for IPhone 7 enough ordinary photos (1-2 MB each), for IPhone 10 - 6 photos > 10 MB, example )
  • Open 1-1 chat
  • Tap on image
  • Tap on library

Additional Information

  • Status version: nightly 16/07/2020
  • Operating System: iOS

Logs

default 17:37:01.622607+0200 SpringBoard Received request to activate alertItem: <SBUserNotificationAlert: 0x10658c5f0; title: “Status - Private Communication” Crashed; source: appstored; pid: 870>
default 17:37:01.622697+0200 SpringBoard Activation - Presenting <SBUserNotificationAlert: 0x10658c5f0; title: “Status - Private Communication” Crashed; source: appstored; pid: 870> with presenter: <SBUnlockedAlertItemPresenter: 0x283469990>
default 17:37:01.623066+0200 SpringBoard Acquiring visible modal alert assertion (0x283ba06f0) for presenter: (null)
default 17:37:01.623120+0200 SpringBoard <0x10658c5f0> Presentation state changed to Appearing
default 17:37:01.623174+0200 SpringBoard SBIdleTimerGlobalCoordinator - updateIdleTimerForReason:"IdleTimerReset"]
default 17:37:01.636198+0200 SpringBoard Push: <SBAlertItemWindow: 0x10fa0f2c0>
default 17:37:01.636255+0200 SpringBoard Evaluate: making new window key: <SBAlertItemWindow: 0x10fa0f2c0>, for reason: push
default 17:37:01.636311+0200 SpringBoard updateKeyboardFocusDeferringRules: SpringBoard gets focus for reasons:(systemModalAlert, noKeyboardFocusProcess)
default 17:37:01.636377+0200 backboardd new deferring rules for pid:846: (
"{<environment=system> -> <pid=846 token=1a9e71a4> : 1-deferDiscrete: systemGestures}",
"{<environment=keyboardFocus display=builtin> -> <pid=846 token=289b38c0> : 1149-deferDiscrete: Key Window event focus deferral}",
"{<environment=keyboardFocus display=builtin> -> <pid=846 token=d9507287> : 1150-deferDiscrete: Key Window event focus deferral}"
)
default 17:37:01.651292+0200 backboardd new resolutions for pid:846 {(
<display=builtin environment=cameraButton pid=846>,
<display=builtin environment=keyboardFocus pid=846 token=d9507287>,
<display=null environment=system pid=846 token=1a9e71a4>
)}
default 17:37:01.653165+0200 backboardd new deferring rules for pid:846: (
"{<environment=system> -> <pid=846 token=1a9e71a4> : 1-deferDiscrete: systemGestures}",
"{<environment=keyboardFocus display=builtin> -> <pid=846 token=d9507287> : 1150-deferDiscrete: Key Window event focus deferral}"
)
default 17:37:01.662120+0200 SpringBoard Ignoring interaction events for reason: default -- count: 1
default 17:37:01.662723+0200 SpringBoard Added: <UIApplicationSceneDeactivationAssertion: 0x28398b750; reason: systemModalAlert; all scene levels; hasPredicate: YES>
default 17:37:01.662770+0200 SpringBoard updateKeyboardFocusDeferringRules: SpringBoard gets focus for reasons:(systemModalAlert, noKeyboardFocusProcess)
default 17:37:01.666037+0200 locationd os_transaction created: (<private>) <private>
default 17:37:01.666081+0200 locationd os_transaction released: (<private>) <private>
default 17:37:01.666244+0200 backboardd new key command registrations for pid:846: <BKSMutableHIDEventKeyCommandsRegistration: 0x11be0be40; environment: keyboardFocus> keyCommands = {
<BKSHIDEventKeyCommand: 0x11be84ee0; input: UIKeyInputEscape>;
<BKSHIDEventKeyCommand: 0x11beba450; keyCode: 33; modifierFlags: shift | command>;
<BKSHIDEventKeyCommand: 0x11be56f30; input: q; modifierFlags: control | command>;
<BKSHIDEventKeyCommand: 0x11be431a0; input: h; modifierFlags: command>;
<BKSHIDEventKeyCommand: 0x11be845c0; input: q; modifierFlags: command>;
<BKSHIDEventKeyCommand: 0x11be73830; input: " "; modifierFlags: command>;
<BKSHIDEventKeyCommand: 0x11be5b4c0; keyCode: 32; modifierFlags: shift | command>;
}

Nightly log: console-log-ios.log
1.4.1 log: console-crash-release.log

1.5 bug high-priority ios

Most helpful comment

thanks, I agree! I took a couple of RAW unprocessed photos that are super heavy, it made the images take a while longer to show up but i didn't get any crashes. I'm on iOS14 Beta so maybe there it's somewhat less of an issue if at all. Also, Discord is React Native, they have the same UI for images and no issues there at all, no lag like ours. so imo it's some flaky implementation we're using

All 12 comments

cc @hesterbruikman @Serhy

@cammellos this issue has cropped up. Can you please check if you can think of a reasonable solution? I hate to say it, but if it takes more than a day we'll need to release with it. Delay is more harmful

I can confirm there is the same on iPhoneX too, but when 'Latest photo preview' pulls panoramas (4 latest photos are panorama is enough).
Having regular photos in 'Latest photo preview' on iPhoneX works fine for me, but a few of 10MB images already "too heavy" for Status to process.

It depends on how heavy photo is taken for Recents section.

On Android I don't see crashes. But it's either empty 'Recents' view or since some time photos (even 6Photos*20MB) are displayed.

So crash of heavy (depends of device) apparently only iOS issue.

The app is getting killed by the OS:
default 16:15:35.283839+0200 kernel 86430.210 memorystatus: killing_specific_process pid 1812 [StatusIm] (per-process-limit 10) 1484802KB - memorystatus_available_pages: 32414
seems like either we use too much memory or there's some leak somewhere.
Not sure exactly what the solution would be, we need to look at the code/ libraries that do image showing/processing, I can take a look, but likely is not a one day fix, but we might get lucky

Any more insights @cammellos ?

@errorists Sadly the gallery preview of images is causing issues :/

  1. This 👆 issue on heavy photo's crashing the preview on iOS
  2. The preview not loading images when you first open it on Android

What would be the impact on the UI if we were to remove it for 1.5?

Monosnap_2020-07-17_12-09-40

christ on a stick I can't take it anymore 😭

Frame 6

What would be the impact on the UI if we were to remove it for 1.5?

I would have to redesign the entire thing around camera capture instead and we would need to reimplement, we can't just leave it like that with a huge empty void of nothingness :(

just to add: currently even without these issues the order of images in gallery preview is random, so IMO it doesn't make a lot of sense for user.

order of images in gallery preview is random

ok so that is clearly a bug that needs to be fixed

For Android it just takes lightweight images, like screenshots;
For IOS as well if it is not crashed.

testing on iOS now, I see all of the actual photos I took, just not in the correct order, half of them start from left and the other half from right

It sucks, but lets move on, knowing these issues. We can't afford more delays and while the issues are serious, they're not putting funds or security at risk and crash on iOS is a % of a % of the userbase

thanks, I agree! I took a couple of RAW unprocessed photos that are super heavy, it made the images take a while longer to show up but i didn't get any crashes. I'm on iOS14 Beta so maybe there it's somewhat less of an issue if at all. Also, Discord is React Native, they have the same UI for images and no issues there at all, no lag like ours. so imo it's some flaky implementation we're using

Was this page helpful?
0 / 5 - 0 ratings

Related issues

annadanchenko picture annadanchenko  ·  3Comments

errorists picture errorists  ·  3Comments

andmironov picture andmironov  ·  3Comments

rachelhamlin picture rachelhamlin  ·  3Comments

lukaszfryc picture lukaszfryc  ·  3Comments