Immediate crash on startup (5.10)

[AaronVanGeffen]

• I have searched open and closed issues for duplicates
• I am submitting a bug report for existing functionality that does not work as intended
• This isn't a feature request or a discussion topic

---

Bug description

After updating the Signal iOS app to v5.10.0.49, the app immediately crashes on launch. I only see the splash screen for a fraction of a second.

Steps to reproduce

• Open the app
• See the splash screen for 0.2s
• Immediately get kicked back to springboard

Actual result: Crashes to springboard

Expected result: Doesn't crash and shows list of chats

Device info

Device: iPhone 12 Mini

iOS version: 14.5 (but happened on 14.4.2 as well)

Signal version: 5.10.0.49

Link to debug log

Unfortunately, Signal no longer opens at all, so I cannot enable the debug log. However, please find the latest crash report here: Signal-2021-04-27-122343.ips.zip

[cityrolr]

Can confirm this bug on iPhone 12 Pro with iOS 14.5 and previous one. I have handed in multiple crash reports via Apple as well.

[fridtjof]

I'm experiencing the same issue since the update.

• iPhone 7
• iOS 14.5

[AaronVanGeffen]

Unfortunately, upgrading to 5.11 has not resolved the issue for me. This is on iOS 14.5.1.

[snacks]

I'm experiencing the same issue.

iPhone 7
iOS 14.5.1
signal v. 5.10

[fridtjof]

Still happening on 5.11.1

[beret]

Crash occurs immediately after upgrade from Signal 3.9.1 to Signal 5.11.1 on a fresh restore to iOS 14.4 - iPhone SE (Gen 1)
Persists across device restarts.
Just like the original report, crash is in GRDB Storage.writer with Address size fault.

This message database was recently transferred from another 3.9.1 device. Following migration data was accessible. First launch of 5.11.1 showed database upgrade progress bar which did make some progress, followed by the first attached crash. One example subsequent crash at launch (after a device restart) also attached.

Issue also remains on TestFlight Beta 5.12.0.46, which on first launch briefly shows pulsing text for optimizing database, and then crashes to springboard. Subsequent background launches also immediately show a crash notice.

Safe workaround: Use Signal Desktop if already setup.

DANGEROUS
Workaround: Using the TestFlight Beta enroll and then downgrade to 5.9.0.46. This is dangerous as downgrades are unsupported. It worked for me with no apparent issues, but DO NOT DO IT unless you are willing to risk losing your message database.

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000019b77eaa8
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [1195]
Triggered by Thread:  7

Thread 15 name:  Dispatch queue: GRDB Storage.writer

Thread 15 crashed with ARM Thread State (64-bit):
    x0: 0x00000002838db560   x1: 0x000000018a6e4cb4   x2: 0x0000000000007103   x3: 0x0000000107d086a0
    x4: 0x0000000000000140   x5: 0x0000000107d086a0   x6: 0x0000000000000016   x7: 0x00000000000003f8
    x8: 0x00000002838db568   x9: 0x0000000200000003  x10: 0xfffffffe00000000  x11: 0x0000000000000000
   x12: 0x0000000000000003  x13: 0x00000000ab342a5c  x14: 0x00000000ab342a38  x15: 0x000000000000245a
   x16: 0x00000001cf1c79b8  x17: 0x0000000001000004  x18: 0x0000000000000000  x19: 0x00000001062fd824
   x20: 0x0000000000000000  x21: 0x0000000000000000  x22: 0x000000000000002e  x23: 0x00000001062cd7f0
   x24: 0x00000002838db560  x25: 0x30000000000000a9  x26: 0x000000000000000b  x27: 0x0000000000000002
   x28: 0x0000017273384336   fp: 0x000000016dc29ec0   lr: 0x000000018a416aa8
    sp: 0x000000016dc29e40   pc: 0x000000018a416aa8 cpsr: 0x60000000
   esr: 0xf2000001  Address size fault

Signal-2021-05-11-14.4.zip

[TobiasKaiser]

I am experiencing the same issue with Signal 5.11.1 on iOS 14.5.1, iPhone 12 mini. I think the problem started after an automatic upgrade to Signal 5.11. When launched, the app crashes immediately and therefore is completely unusable.
I have also sent the ips debug file to Signal's support team and am hoping for a soon fix.

[cityrolr]

After communicating with Signal 2 weeks ago on this issue, I think this issue won’t be fixed anytime soon. It seems to be an old bug related to transferring data from one device to another. The suggested solution was to re-install Signal incl. the loss of history.

[beret]

Darn, that’s concerning. Especially since this seems like a pretty clear regression from 5.9 which I can confirm works without issue without any change to user data. I do see a recent closed issue #4963 with the database at launch, but that was not a crash, and was supposedly fixed in 5.9.

…

On May 16, 2021, at 11:14 AM, Julian Mair ***@***.***> wrote:  After communicating with Signal 2 weeks ago on this issue, I think this issue won’t be fixed anytime soon. It seems to be an old bug related to transferring data from one device to another. The suggested solution was to re-install Signal incl. the loss of history. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[TobiasKaiser]

Thanks for the feedback. I have reinstalled Signal now. Though I have lost my messaging history, the app works now again at least.

[beret]

Workaround Update:
The Test Flight workaround to use 5.9 will expire in 9 days.

Data migration from Signal 5.9 on an iOS device (A) to another iOS device (B) running Signal 5.9 is successful but does not resolve the issue. Any update to 5.10+ again results in crashes on B.

Migration also completes from device B (Signal downgraded back to 5.9) to device A running Signal 5.15 (Test Flight.) Signal 5.15 then immediately crashes on first launch, but the data is accessible on device A after it is again downgraded to 5.9.

I now have debug logs of some of these crashes as well. I have also reproduced this these crashes (using the same data) on an iPhone 12 Pro on iOS 14.6 by doing a device to device migration in Signal, and then migrating back to the original iPhone SE (gen 1) iOS 14.6.

Crash behavior is identical on both. Debug logs are pulled from the iPhone SE.

Relevant debug log file: org.whispersystems.signal.2021-06-30--01-02-41-469.log

Related time stamps, sequence notes are below:

2021/06/30 01:02:43:848 - Crash after device to device migration

2021/06/30 02:02:39:880 - Crash after app updated

Tested Scenarios

Device A (SE) - Signal 5.9 > Device B (12 Pro) - Signal 5.9
Successful migration, data accessible.
First launch OK.

Upgrade Signal on Device B (12 Pro) - Signal 5.9 to Signal 5.15
Crash on first and all subsequent launches.

Downgrade Signal on Device B (12 Pro) - Signal 5.15 to Signal 5.9
Successful downgrade, data accessible.
First launch OK.

Device B (12 Pro) - Signal 5.9 > Device A (SE) - Signal 5.15
Successful migration. App on iPhone SE crashes immediately after migration completes. (2021/06/30 01:02:43:848)
All after-migration launches also crash.

Downgrade Signal on Device A (SE) - Signal 5.15 to Signal 5.9
Successful downgrade, data accessible.
First launch OK.

Upgrade Signal on Device A (SE) - Signal 5.9 to Signal 5.15
Crash on first and all subsequent launches. (2021/06/30 02:02:39:880)

Downgrade Signal on Device A (SE) - Signal 5.15 to Signal 5.9
Successful downgrade, data accessible.
First launch OK.

org.whispersystems.signal 2021-06-30--01-02-41-469.log

[elahmo]

This is still happening, any potential fixes for this?

Signal-2021-03-15-020901.ips.zip

[beret]

Based on my reading of the crash logs I posted above, it looks like this is likely something inside of group chat tables in the database, but there’s a number of commits changing those parts in 5.10. So it’s definitely fixable but I have no idea if it’s being worked on. (I did also email the updated crash logs and debug (much more useful) logs to support last week.) The test flight hack can at least buy you a few days of functionality until it expires again. (Slightly less destructive than destroying all of your chats: while you’re in there you could try nuking group chats until the ones that are mishandled are removed? But that’s gross and not really a solution since there’s fundamentally nothing wrong with our databases… It’s just a fixable regression.)

…

On Jul 4, 2021, at 8:02 AM, Ahmet Novalić ***@***.***> wrote:  This is still happening, any potential fixes for this? Signal-2021-03-15-020901.ips.zip — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[elahmo]

In my case its not applicable, as the app crashes as soon it starts. This has happened a few months ago, requiring a reinstallation, and now it is happening again. This has never happened with other services I have been using for 5-6 years, so its quite a major bug preventing widespread adoption of Signal.

[beret]

Yeah, I have those exact crashes on startup when I’m on 5.10 or newer. I’ve been working around it for the past few months by picking the older 5.9 version in the test flight beta program. (See above) But that expires in a couple days and then we’ll just be stuck using desktop signal unless we want to destroy years of data.

…

On Jul 4, 2021, at 10:51 AM, Ahmet Novalić ***@***.***> wrote:  In my case its not applicable, as the app crashes as soon it starts. This has happened a few months ago, requiring a reinstallation, and now it is happening again. This has never happened with other services I have been using for 5-6 years, so its quite a major bug preventing widespread adoption of Signal. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[beret]

Issue remains in versions past 5.10.

Common signatures in crash logs:

Start of migration at launch:
💛 [GRDBSchemaMigrator.swift:17 runSchemaMigrations()]: Using incrementalMigrator.
💛 [GRDBSchemaMigrator.swift:181 registerMigration(_:migrate:)]: Running migration: dataMigration_populateGroupMember

❤️ [SDSDeserialization.swift:21 required(_:name:)]: Missing required field: viewed.
❤️ [TSInteraction+SDS.swift:4133 grdbFetchOne(sql:arguments:transaction:)]: error: SDSError.missingRequiredField
[LAST TWO LINES REPEAT, MAY NOT BE FATAL]

When stacktrace is logged, about a second later:
[SDSRecord.swift:68 sdsInsert(transaction:)]: Insert failed: SQLite error 19: UNIQUE constraint failed: model_TSGroupMember.uuidString, model_TSGroupMember.groupThreadId

Related commits in 5.10

bf660c8 Adding TSGroupMember table populated by review of all past threads. Crash occurs during initial table population.

The viewed field was added after the initial issue report, so is likely unrelated to the original issue:
db3e441 Adding viewed field to SignalServiceKit/src/Messages/Interactions/TSInteraction+SDS.swift causing Missing required field: viewed during dataMigration_populateGroupMember

Unfortunately I don't have debug logs for others in thread, or a testing harness to safely work against my actual data, but this does appear to be a tractable issue scope considering full data access when on 5.9.

[beret]

I’ve identified my crash in the TSGroupMember table handling.
(
I don't know if this is the same crash others are seeing; but I was also able to repair and migrate my data to the latest releases.)

Cause

My issue was that TSGroupMember was partially populated with ~20 entries, presumably from an aborted migration. Subsequent incremental migrations would retry populateGroupMember and crash when inserting a row that conflicts with the prior attempt's entries.

Signal crashes with the UNIQUE uuidString constraint mentioned above, rather than gracefully skipping or updating existing data, or dropping/cleaning the table and starting over. (The latter appears a reasonable option, less state to track, and TSGroupMember is a byproduct of the larger interaction data.)

IDR exactly how my initial 5.9 > 5.10 migration happened, but I was using an iPhone SE Gen 1, and it was likely just high resource competition during the upgrade causing a termination.

Recovery

I did recovery via a jailbroken phone (thanks @seb2point0!), used AppStore++ for arbitrary Signal testing upgrades/downgrades, copied off the DB and keychain key, inspected and tested queries against a decrypted copy, modified the encrypted sqliteDB with sqlcipher as below, and finally reinstalled signal.sqlite over SFTP/SSH.

UPDATE "main"."model_TSInteraction" SET "viewed"=0;
DROP TABLE "main"."model_TSGroupMember";
DELETE FROM "main"."grdb_migrations" WHERE "identifier"='addGroupMember';
.tables
.quit

Changes were manually dropping the TSGroupMember table, removing the addGroupMember migration action in the grdb_migrations table, and setting all TSInteraction viewed: null fields to 0 for good measure. There was a minor inconsistency there due to my failed 5.10+ upgrade (which added viewed and set 0) since messages received after my downgrade back to 5.9 then had that unset as null.

Upon putting in the fully repaired DB, the migrator created TSGroupMember fresh, populated it without issues, and connected to the network.

Caveats



keychain_dumper -gn is hit by rate limiting on the Secure Enclave, so you should manually grant entitlements to only include the needed group(s): https://gist.github.com/beret/8f6347139974f824af1c8167530e9a7f (Or grant all, but scope your retrievals to U68MSDN6DR.org.whispersystems.signal

)

Permissions: mobile:mobile 644 file/755 directory

For about one or two weeks I had slow message sends on launch, as on each launch Signal would apparently try to retrieve missing Interactions and would churn the CPU reprocessing the whole DB. It appears this mitigated itself after maybe those attempts all timed out.

Some data (about the most recent month) was synced back from my desktop Signal client (I think) onto my phone. Older messages in that span remain desktop only. This DB has now completed round-trip migrations between iPhones without issue.

I disabled background updates for Signal and force-killed it in Springboard to minimize the risk of data inconsistency. Airplane mode may not hurt either. YMMV. Low risk since 5.9 is already blocked from the Signal network.


As this timespan overlaps with some group upgrades, some of my old and inactive groups finally got upgraded. People who had already lost references to these groups saw new messages that I had added them and others to "group name." No other known impacts for conversation partners.

FYI @Imperiopolis-Signal - Since this relates to bf660c8

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.