After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755584 - remove_operations_button_attention_style: Unsafe timeout handling
remove_operations_button_attention_style: Unsafe timeout handling
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Crashers
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-24 20:15 UTC by Matthias Clasen
Modified: 2015-10-06 17:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
toolbar: remove operations button timeout correctly (3.40 KB, patch)
2015-10-06 16:53 UTC, Carlos Soriano
committed Details | Review

Description Matthias Clasen 2015-09-24 20:15:58 UTC
Here is a f23 crash report:

https://retrace.fedoraproject.org/faf/problems/bthash/?bth=3e843c8b22e93b1c6be557a86b6694c61c0161fb&bth=68aba2555a4c1308bd8fac8ec694c1e12f20963e&bth=7739bf887bd56ac532b04fbcab40e54f2730d953

I think what is happening here is that remove_operations_button_attention_style removes the timeout_id *without* removing the actual timeout. I guess you assumed that returning G_SOURCE_REMOVE is good enough. And it is, but only if you return it from an actual timeout. This function is also called from add_operations_button_attention_style (why twice in a row, btw ?). And this leads to the timeout_id being reset without the scheduled timeout getting cleared. And if you  are then quick enough to close the window, the dispose() handler will not see the timeout_id, thus not remove the timeout either. And then the timeout gets eventually run and accesses the already-finalized toolbar.
Comment 1 Carlos Soriano 2015-10-06 16:53:40 UTC
Created attachment 312749 [details] [review]
toolbar: remove operations button timeout correctly

We were resetting the id to 0 without actually removing
it in the case a timeout was already there and we tried
to set a new one.
Comment 2 Matthias Clasen 2015-10-06 17:08:57 UTC
Review of attachment 312749 [details] [review]:

looks good to me
Comment 3 Carlos Soriano 2015-10-06 17:15:07 UTC
Indeed, pushed a fix
Attachment 312749 [details] pushed as 9ee7c17 - toolbar: remove operations button timeout correctly