iOS client instantly crashing with large attachments

Mutual Help
1

Delta Chat version
1.46

Expected behavior

App is working correctly

Actual behavior
iOS app instantly crashes after showing splash screen for a while. Problem can solve by itself after indefinite amount of time (from 10 minutes to 24-36 hours)

Steps to reproduce the problem
0. (To break sender’s side) Enable sending copy to yourself

  1. Send a large video attachment from an Android app via postfix+dovecot server to user at the same server
  2. Open recipient’s iOS app — it crashes
  3. Open sender’s iOS app — it crashes

But it isn’t reproducible every time for both sides: sometimes both clients are broken, sometimes one of the them, sometimes both work correctly.

No logs could be retrieved, because app does not open. Nothing suspicious in the dovecot logs have seen.

1 Like
2

I made an issue for it on the iOS repo: iOS client instantly crashing with large attachments · Issue #2210 · deltachat/deltachat-ios · GitHub

1 Like
3

thanks a lot for your report! to make it easier to sort things out, maybe you can clarify the following points:

which size were you using got a “large video” - how many MB or even GB?

for 3. the “sender’s iOS app” - in 1. the sender was Android app. might be, of course, that Android is affected as well.

in general, for sure, we need some upper borders - in the past, core was restricting sizes, but that was removed completely, so we need some checking in the apps (eg. iOS has a very strict limit about the amount of memory an app can use - maybe this is just hit)

4

which size were you using got a “large video” - how many MB or even GB?

about 17 MB

for 3. the “sender’s iOS app” - in 1. the sender was Android app. might be, of course, that Android is affected as well.

The sender was an Android app, yes, but it does not crash

eg. iOS has a very strict limit about the amount of memory an app can use - maybe this is just hit

It may be the case, because more messages with large attachments in a series you send – more likely the problem will reproduce

BTW, at this postfix instance message_size_limit = 104857600

1 Like
5

hm, i tried to send myself several files/videos, but i could not reproduce the issue. the video was a raw size of 20mb, resulting in a message of about 30mb - which is the upper limit for the used email sever - larger files are denied to sent out.

@Simon as you created the issue in the iOS repo, i assume, you could reproduce that? if so, can you provide a log or give more information about how to reproduce and how “download on demand” is related to that?

otherwise, maybe the crash is not related to file size, but to actual file content, @JoeMcNuggets can you send the video/file in question to Message privately on Delta Chat

1 Like
6

Haven’t tried it, just reposted it there, because I didn’t know how actively you were watching the forum, it’s a bug report, not a feature request, so it belongs to iOS issue tracker.

7

I believe a friend of mine is suffering from this issue. DC on iOS (Appstore version) not opening after I sent him a 5 MB GIF from my DC Windows client. No issues viewing the chat, message and attachment on my testflight version. He is on Chatmail, I’m on vanilla Dovecot.

8

Well, I cannot reproduce crashes anymore, but now it instead of crashing app is hanging in the “Updating” state for a long time.

The strangest think is here: I’ve sent the message with a big (~18mb) attachment at 22:15. Recipient had no push notification and hang with “Updating” header. And there are no records regarding that time period at all. Recipient got the message at 23:28

image
image591×1280 142 KB

image
image591×1280 110 KB

Unfortunately I cannot provide you that file, but here’s it’s characteristics:

Input #0, gif, from '/home/art/Загрузки/that.gif':
  Duration: 00:00:06.36, start: 0.000000, bitrate: 23836 kb/s
  Stream #0:0: Video: gif, bgra, 640x360, 25 fps, 25 tbr, 100 tbn

Also I tried to provoke that behaviour with that gif on the another iOS device with another recipient and couldn’t reproduce, event after sending tens of them.

9

Аналогичная проблема. После отправки клиенту на иос большого файла, приложение не открывается. Висит на логотипе. Был отправлен лог файл, текстовый (name.log) около 30мб.

1 Like
10

Reproduced againt with a 13 mbytes video. Latest iOS client stucked in updating, can send messages, but can’t receive any.

Logs are the same as I provided earlier

Also, expunging the message with video attachment from recipient’s mailbox at Dovecot fixes the issue.

11

Some interesting details: while expunging latest message with video from DeltaChat mailbox with 15 mbytes attachment, I saw that entire mail was about 21 mbytes

Also, if there’s a reply to the message with a large video attachment, you have to expunge mail with reply too to make iOS app receiving messages again

12

I think the size difference of the attachment is normal due to the base64 encoding and encryption.

13

@Raiden, yes, but I thought that it could be cause of hitting some unknown limit.

Here’s some updates on this issue: even sending large video with this WebXDC App with chunks by 3 Mbs is causing stucking at “updating” status.

So it seems like a problem is definitely at the iOS client side. Furthermore, I suspect that problem is not related to deltachat-core, but to deltachat-ios.

1 Like
14

Assuming that:

  • this issue is iOS-specific,
  • it can be reproduced even when file is sent with chunks by WebXDC-app,
  • it happens when attachment size is about 20-30 megabytes,
  • in my case chats are very big (mailbox is over 10 gigabytes),

I think the problem lays near memory limits of an iOS. For example, some background workers or threads got killed without crashing the entire app.

I am not an expert in iOS and DeltaChat iOS client, but, for example it could be the next pattern:

  • some NSOperation is scheduled
  • while fetching and processing messages this operation hits memory limit and crashes
  • after removing message from mailbox on Dovecot by hand, rescheduled operation successfully pulls other messages

AFAIK, if NSOperationQueue tasks exceeds memory limits, iOS can terminate background workers without terminating the main process.

UPD: successfully reproduced issue on my iPad Pro 2020:

  • open saved messages on Android app
  • share a 244 mbytes file by 3 mbytes chunks with Sharer WebXDC
  • open iOS client
  • open Sharer at iOS client
  • ensure downloading started
  • turn off screen on Android and iOS
  • return after N minutes
  • open iOS client
  • download stuck at 48/52 chunks
  • DeltaChat status stuck at “updating”
1 Like
15

This could also be due to the fact that iOS or iPadOS does not allow an app to be permanently active in the background. :thinking:

1 Like
16

This issue happens because the notification process gets killed when it uses over 24mb (12mb on older devices / iOS versions) and decrypting a message with a 5+mb file often takes more.

The notification process getting killed has two effects.

  • The notification is not shown to the user in the Notification Center
  • The app thinks the notification process is still running and will wait for 30 seconds.

Before this PR in November 2024 the waiting happened on the splash screen, afterwards it showed “Updating…” while waiting.

Once this is merged and released we will show a generic notification and reduce the waiting period after failing to decrypt due to memory constraints.

It can be refined in the future but this hopefully makes the issue less obnoxious.

3 Likes