Description of problem: If you let evince in full screen mode, it'll crash in the next launch (only the first launch, then it'll work ok) Fedora 23 Cinnamon 2.8.4 Version-Release number of selected component: evince-3.18.2-2.fc23 Additional info: reporter: libreport-2.6.3 backtrace_rating: 4 cmdline: evince /home/neil/Documentos/Text/Books/Happiness-Beyond-Thought-A-Practical-Guide-to-Awakening.pdf crash_function: g_type_check_instance executable: /usr/bin/evince global_pid: 2487 kernel: 4.2.7-300.fc23.x86_64 runlevel: N 3 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 g_type_check_instance at gtype.c:4138 #1 g_signal_handler_disconnect at gsignal.c:2620 #2 ev_page_action_widget_set_document at ev-page-action-widget.c:265 #8 g_object_notify_by_spec_internal at gobject.c:1154 #9 g_object_notify at gobject.c:1202 #10 ev_document_model_set_document at ev-document-model.c:381 #11 ev_window_load_job_cb at ev-window.c:1727 #12 _g_closure_invoke_va at gclosure.c:864 #15 emit_finished at ev-jobs.c:181 #19 g_main_context_iteration at gmain.c:3901 Potential duplicate: bug 1191772
Created attachment 1107854 [details] File: backtrace
Created attachment 1107855 [details] File: cgroup
Created attachment 1107856 [details] File: core_backtrace
Created attachment 1107857 [details] File: dso_list
Created attachment 1107858 [details] File: environ
Created attachment 1107859 [details] File: exploitable
Created attachment 1107860 [details] File: limits
Created attachment 1107861 [details] File: maps
Created attachment 1107862 [details] File: mountinfo
Created attachment 1107863 [details] File: namespaces
Created attachment 1107864 [details] File: open_fds
Created attachment 1107865 [details] File: proc_pid_status
Created attachment 1107866 [details] File: var_log_messages
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 1280106 has been marked as a duplicate of this bug. ***
cannot reproduce fullscreen crash in current F24. action_widget->doc_model is apparently a weak pointer if it were 0 that would explain it but gdb shows it as non-0. the glib docs say that this weak reference isn't thread safe so it's theoretically possible that another thread deletes the object concurrently but i don't know enough about evince to say if that is possible. upstream bug with very similar stack: https://bugzilla.gnome.org/show_bug.cgi?id=756515 ... which i can't reproduce either. ev_document_model_set_document calls g_object_notify (object=0x5616082b60c0, ... but then ev_page_action_widget_set_document calls g_signal_handler_disconnect (instance=0x5616086045b0, ... is it expected that there are 2 different instances of EvDocumentModel? the only place where EvDocumentModel is created is ev_window->priv->model = ev_document_model_new (); in ev_window_init() the signal that is being broadcast here has a handler registered from ev_page_action_widget_set_model, but that handler is never unregistered. so it could be possible that ev_page_action_widget_set_model is called twice, and the second call sets a model that is then destroyed before the first one emits this "notify::document" signal. but i think i'm not able to fix this if i can't reproduce it, so i'll just close it upstream since there is already an upstream bug about it, maybe somebody will fix it...