Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signal Desktop unlinks from the Android app and restarts as if never linked before (all history lost). #797

Closed
rdbcasillas opened this issue May 18, 2016 · 26 comments

Comments

@rdbcasillas
Copy link

  • [ X] I have searched open and closed issues for duplicates

Bug description

I closed Signal Desktop for few hours (not for the first time). Open it again and it turns out that it has unlinked from the Android app and makes me go through all the steps again with QR code linking etc. (all history on Desktop app is lost of course). Signal Android did show the laptop as a linked device at the time of this event. After re-linking, as expected, none of the lost messages (not completely lost because they exist on Signal Android) on Signal desktop are seen again.

Steps to reproduce

Seems like a one off event, don't think I can reproduce this.

Platform info

Operating System: OSX El Capitan 10.11.3
Browser: Chrome
Signal version: 0.12.4

Link to debug log

The debug log is after the app was restarted and relinked with with Signal Android. So there doesn't seem to be relevant information there because it starts up as if for the first time. But I still wanted to point out this behavior. The timestamp when this event happened was around 19 hours ago (which is approximately the timestamp for the first log).
https://gist.github.com/b83ee0c4fad0f7d0a23185743b54bed2

Please let me know if more information is required.

@liliakai
Copy link
Contributor

Sounds like #718.

@SwartzCr
Copy link

This has happened to me multiple times now (at least 2, maybe more)

@rdbcasillas
Copy link
Author

In trying to isolate the problem, I figured that its possible that likelihood of this bug increases when disk space is very low. Can anyone else try to replicate this?

@morvans
Copy link

morvans commented Jun 20, 2016

I can confirm I've been bitten by this bug twice, in low-disk space condition each time. There must be a way to prevent whole deletion of history in such situations.

@liliakai
Copy link
Contributor

Has anyone seen this when they were definitely not low on disk space?

@SwartzCr
Copy link

I for sure am habitually low on disk space so totally a possibility for me

On Jul 28, 2016 6:14 PM, "Lilia" [email protected] wrote:

Has anyone seen this when they were definitely not low on disk space?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#797 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnqhI9qN4UlXEbnBb0CqWEXS2eGq_dDks5qaSnIgaJpZM4IhUyg
.

@SuperHaze
Copy link

I'd like to add to this, this is easily re-producable if you manually unlink desktop.

For exmaple, if I manually un-link desktop from Android, then let some time pass, when I re-link with desktop (even if it has been days in between) signal desktop will appear exactly as it did just before it was unlinked. So, any messages in between do not appear.

This is an issue since I often must un-link desktop since I have a shared computer.

@Trolldemorted
Copy link
Contributor

how is this related to this issue?

@irieger
Copy link

irieger commented Oct 23, 2016

Can confirm this bug. Just happend to me the second time. Last time was when I shut down my MacBook before going on a week of holidays. When I came back, Signal was unlinked. Same happend today.

I can confirm that my MacBook is always low on Space. (Have around 10-20 GB free in theory but Safari and other software caches so much that the space sometimes drops to nearly zero when in use for a few days.)

@SwartzCr
Copy link

This just happened to me - here's the debug log: https://gist.github.com/cc29164c7ecb49240f941f2b5009df2c
The situation that caused it is probably reproducible! I was trying to call splitlines in bpython on a file that was 58,000,000 lines long, which caused my process load to hit the high 20s and probably ate all my memory. The result was that both bpython and signal crashed, and it wanted to re-link as a result

@liliakai
Copy link
Contributor

Looks like maybe you didn't lose all your messages this time though?

@SwartzCr
Copy link

it's true! I didn't but it did force me to re-link

@liliakai
Copy link
Contributor

FYI I think you experienced a different bug where the re-link screen pops up unnecessarily, but actually you can just close it and re-launch the app normally. 😉

@deutrino
Copy link

What would be the best way to generate debug logs? I've had this happen enough when my disk filled up that I can probably reproduce it.

@scottnonnenberg
Copy link
Contributor

@gordon-morehouse Grab debug logs the standard way - the triple-dot menu on the left, then Submit debug log. It may not be fruitful if you're losing all of your data, however, since that log is stored in the same places as your messages. Still, it's worth a try!

@deutrino
Copy link

I'll try to reproduce this by filling my disk and seeing what happens when I have time. It's happened to me several times so it shouldn't be difficult. Maybe I can grab logs before shutting down the browser, I think the Signal instance stays running - sort of - until a browser restart? We'll see.

@PabloCastellano
Copy link

PabloCastellano commented Jul 29, 2017

It just happened to me. As per @liliakai and @SwartzCr comments, looks like running out of space might be the cause. I have run out of space and possibly some chromium file got corrupted (also I'm using ecryptfs).

@mutantmonkey
Copy link

mutantmonkey commented Sep 17, 2017

I've had this happen to me twice now, with plenty of available disk space both times. In both cases, it's happened when the IndexedDB has been quite large due to having multiple videos in my conversation history.

My debug log doesn't have any information about this, but Chromium did spit out the following:

LevelDB get failed: Corruption: block checksum mismatch
IndexedDB Read Error: LOAD_CURRENT_ROW
IndexedDB recovering from a corrupted (and deleted) database.
IndexedDB backing store open failed, attempting cleanup
IndexedDB backing store cleanup succeeded, reopening

@deutrino
Copy link

I didn't get around to reproducing this before switching to Electron, but it might be worth noting that I was also using ecryptfs.

@scottnonnenberg
Copy link
Contributor

Holy crap, that is some intense logging from IndexedDB. Sorry that's happening to you! Can you tell us anything about your message volume and usage patterns? Since it has happened to you twice, any idea what the trigger is? What pushes it over the edge into data loss?

@mutantmonkey
Copy link

I have been able to send several fairly large videos without this happening, so it's definitely not just the action of sending videos that causes this. I unfortunately wasn't able to get an idea of the size of the IndexedDB prior to this happening, but it does seem like having a lot of data in there is a contributing factor.

Both times, it's happened after using Signal Desktop fairly regularly (an average of probably several messages a day) over the course of several months. A few days prior to this happening, I have noticed that Signal Desktop seemed to crash more often than usual, so I'm wondering if that's happening is that a large database makes it more likely to crash, and the crashes are what trigger the corruption. The most recent time this happened, I had it crash on me and act a bit slow after relaunching, although all my messages were still there at that point. It was only the next time I launched it that I ended up with this IndexedDB corruption.

If I get a chance, I will attempt to set up a separate test instance and see if I can reproduce this.

@mutantmonkey
Copy link

Unfortunately, this bug has gotten even worse with Electron. Now, instead of the app fully unlinking, it gets in a weird state where it remains linked but can no longer use the database to read or store messages.

This seems really easy to reproduce now; if you quit Signal Desktop while it's in the middle of receiving a message, the database becomes corrupted. The few logs that I do have don't seem to be useful in any way; the Signal debug log has nothing related to the initial IndexedDB corruption and it otherwise appears to be completely normal.

@scottnonnenberg
Copy link
Contributor

@mutantmonkey Sorry to hear that you're having trouble! I tried reproducing the database corruption you report with Electron v1.0.32+ (dev build) on both OSX and Ubuntu 16.04, and I couldn't do it. I killed the app during heavy database activity a good ten times on each platform, and it still started up fine right afterwards.

Perhaps you could provide the size of your ~/.config/Signal directory? Mine is 4.5MB, since this is a pretty recent link. Any other detail you can provide about your usage patterns would really help. Thanks!

@mutantmonkey
Copy link

mutantmonkey commented Oct 25, 2017

I do still have the config directory from when things got into a weird state and it's 283MB. I also run Signal through a proxy, so maybe this could be related to slower network operations for some reason. (I'm currently using proxychains with Electron, but when using the Chrome app I used the Chrome proxy settings.)

@kpuljek
Copy link

kpuljek commented Nov 21, 2017

Just happened to me on 1.1.0-beta.1

Signal Desktop was running on my PC, I was in the living room chatting. came to my room and noticed that the last few messages weren't synced. So I restart Signal and it asks me if I wanted to set up a new Installation or import an old one. My .config/Signal Beta is reduced to mere 8mb, even though there were months of messages in there, some pictures too.

This is my log, it's quite huge but it happened (to the best of my knowledge) sometime today after 7PM (I noticed it around 10:55PM, so that could narrow things down:
https://gist.github.com/anonymous/ea946aa45b7ebf9afae6fe1fbe5d7c2a

@scottnonnenberg
Copy link
Contributor

Closing this in favor of the more recent #1589.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests