-
Notifications
You must be signed in to change notification settings - Fork 42
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
Potential crashes between source deletion and accessing source in the gui #906
Comments
Here's a list of areas in the code that need attention regarding possible crashes due to trying to access data on a deleted source without catching the exception:
|
Numbers: 1, 2, and 8 have PRs. The rest are still up for grabs. |
Saw # 1 crasher in the list happen today:
|
We discussed today that a naive try/catch strategy around all UI access to widgets that may be tied to deleted database objects is probably the best first iteration to safeguard this. We'll likely not get to this before Monday, but it's one of the highest priority known areas that can cause crashes, so tracking as release blocker. |
Implementing the |
(hit this again today after deleting some sources server-side and starting the client: #906 (comment)) |
Deferring to near-term backlog as it's not been a significant issue for pilot installs so far. We'll revisit this in the next sprint (after the current 4/22-5/6 sprint); given that we do know that there's crash potential here, I do think it should go into 0.2.1/0.3.0 at the latest. |
We saw during the pilot that a new piece of code that was added after this issue was opened caused a segfault. The reason is that we access securedrop-client/securedrop_client/gui/widgets.py Lines 907 to 908 in 5055040
This can be added as part of # 8 in the list above. |
For the 6/3-6/17 sprint, @creviera has agreed to take a time-boxed stab at this to make an initial round of stability improvements, aiming for 8 hours (that should ideally include review, so I recommend making the implementation time-box shorter). |
Update on the progress of this issue: What's been fixed?
What's left?
4. ConversationView :
5. on_reply_sent :
6. SourceConversationWrapper :
7. on_source_change :
9. DeleteSourceMessageBox :
10. ReplyBox :
11. SourceProfileShortWidget :
|
Thanks @creviera for the writeup. Since you've addressed the issues which were straightforward to reproduce and similar to reports we've heard from prod users, we've agreed to defer additional work on this for now, but will pick this issue up again and leave it open for tracking purposes. |
Closing, looks like it was addressed. May reopen as part of a future sync/data model milestone. |
Description
If a sync comes back with deleted sources from the server we delete them locally and then call
update_sources
which will first remove all the source widgets then remove all the conversation widgets for those sources. If a message, reply, or file download job finishes before the source widget is destroyed then it will try to access source.uuid or source.collection in several places in the code and crash the app. I think there is also an issue with a user trying to open a file for the source at this time.To prevent this type of crash we should only access the source db object when absolutely necessary. For instance, it's not necessary to store source on an object when we only need the uuid so we can find a source widget.
The text was updated successfully, but these errors were encountered: