I have:
A contact of mine unregistered recently. I decided to check and see if Signal would now default to sending that contact SMS. Upon opening the contact's conversation view, the application crashed. While reproducing the issue to produce a log, it seems it has worsened, and now Signal crashes on launch, rendering it completely unusable.
I think this is caused by having an existing encrypted conversation with the contact. Looking at the logs, it appears that the identity information is deleted after the user unregisters, but it still tries to access the identity information to decrypt the existing messages. I haven't looked at the relevant code yet, so this is just a guess.
Actual result: Signal crashes.
Expected result: Signal should not crash.
Device: Huwai Nexus 6P
Android version: 7.1.2
Signal version: latest master
I can't open Signal to capture a log without it crashing, but here's a snippet from logcat: https://paste.ee/p/1iAC5
Hey @justin-sleep I don't think this has anything to do with a contact that has uninstalled Signal. It looks like you're running an arbitrary commit off of master that's not a release tag. You can do that, but we only guarantee database schema migrations from one release tag to the next.
From what I can tell, you were running an earlier commit that executed a migration. You then updated to a different commit where that migration was modified (but you didn't pick up the modifications, because it has already run). The net result is that you now have some extra database columns, and are missing a database column ('verified' in this case), which is why it's crashing.
You'll have to either manually apply the changes to the migration using sqlite3, by modifying the source to run the migration, or by reinstalling.
Sorry for opening an issue when it turns out it's not actually related to Signal's development. Would you mind pointing me toward a commit where a migration was run, for reference?
There have been a few changes since the last release tag:
d50775682196839a78c534c96898b07c65480678
5455bdffb2e64f9e45cabfcb677a49fe1d75df43
7e40204eb2454fae86ab309560ca93f86a36de42
76c28cfa7a12b386ce5f62316247e843ceef3290
Well, I'm learning a valuable lesson about the utility of release tags. Thanks for the help, I'll see if I can get this sorted with a debug version.
Was able to resolve the issue by manually creating the 'verified' column (pulled the database to my local machine, added the column, pushed it back). All appears to work now. Thanks!
@justin-sleep where is the db located?
@Trolldemorted /data/data/org.thoughtcrime.securesms/databases/messages.db. The statement in ec240a94e69088b2425f4556d3d805ed9ba7f3cb is the one you need to apply if you're having the same issue.
adb -d shell "run-as org.thoughtcrime.securesms cat /data/data/org.thoughtcrime.securesms/databases/messages.db" > ~/messages.dbadb push ~/messages.db /sdcard/adb -d shell "run-as org.thoughtcrime.securesms cp /sdcard/messages.db /data/data/org.thoughtcrime.securesms/databases/messages.db"Of course, it's a good idea to back up your database before following these steps. Remove the database from your /sdcard/ when done (I didn't use mv to preserve permissions). Note that you'll need to build and install a debug version to use adb run-as. In Gradle, you can do this by using the assembleDebug build task rather than assembleRelease.
I went from 4.6.1 to 4.7.0 and ran into the same problem.
Unfortunately run-as gives me: Package 'org.thoughtcrime.securesms' is not debuggable
What else can I do to fix this?
I recommend everyone transition this discussion over to the community forum to reduce the amount of email spam generated here.
@nrizzio, usually I agree when it comes to discussions. But isn't this a bug here? Maybe I just do not understand the explanation moxie0 gave.
What I did:
I did a fresh install with commit 7e40204eb2454fae86ab309560ca93f86a36de42.
I now built and installed Signal with commit 7c2191f9a0f4ce0d9dc60954fe7ac8c786f3c872.
I don't see whats wrong here... How comes that there's this problem now?
Moxie says that
we only guarantee database schema migrations from one release tag to the next.
...which basically means that if something goes wrong outside of that situation, OWS isn't going to fix it. 7e40204, your starting place, is between the release tags. Since your situation isn't going to receive official support, you should move to the forum, because every additional comment on the issue tracker creates unnecessary notifications for OWS.
Most helpful comment
Moxie says that
...which basically means that if something goes wrong outside of that situation, OWS isn't going to fix it. 7e40204, your starting place, is between the release tags. Since your situation isn't going to receive official support, you should move to the forum, because every additional comment on the issue tracker creates unnecessary notifications for OWS.