GNOME Bugzilla – Bug 693200
Printing via evince crashes badly when /tmp is not writable
Last modified: 2014-03-18 15:05:29 UTC
Created attachment 235204 [details] Evince stacktrace on crash when /tmp is not writable For some reason (maybe lack of space), permissions on my /tmp folder became: drwxr-xr-x 25 root root This causes evince to crash on printing, with the trace attached. Evince must be made more robust on such problems. The problem is easily reproducible an can be of course circumvented by making /tmp writable to all.
*** glibc detected *** evince: double free or corruption (out): 0x00007f6fb8d3a220 *** While nonwritable /tmp may have contributed, this is a memory corruption bug. The bug happened ealier than the crash. Please use valgrind (see https://live.gnome.org/Valgrind ) how to track this down.
Thanks for your response. I was not able to install valgrind, due to a strange dependency issue with libc6-dbg. You can enjoy the crash live (and use whatever analysis tool to trace down the memory bug) by reproducing the failure in the obvious way: chmod 755 /tmp evince whatever.pdf Then try printing the document from Evince. BTW, I'm currently using 3.4.0-0ubuntu1.6
This problem seems to be in gtkprinter (gtk_printer_request_details). It is possible to reproduce with other applications as well. FWIW, my gtk+ version is from May 20, 2013 (a3864ac49f3). Step to reproduce it: 1. sudo chown 755 /tmp 2. open an application like Evince or Gedit 3. Ctrl-P (to print) 4. Segfault. It is not expected the user changes the permission of /tmp, however the reporter did not it by himself. It might be good to catch it instead of crashing.
+ Trace 232068
Thread 1 (Thread 0xb5999ac0 (LWP 5048))
Created attachment 271909 [details] [review] Fail nicely when /tmp is not writable This patch fixes most issues with the non-writable /tmp for me. It is applicable also to 3.10.
Created attachment 271910 [details] [review] Fail nicely when /tmp is not writable (gtk 2.24) The same patch for gtk-2-24.
Review of attachment 271909 [details] [review]: ::: gtk/gtkprintunixdialog.c @@ +2053,2 @@ return; } Does this change make any difference ? Not that there is anything wrong with it, I just don't see how it can be relevant to writable /tmp. Not like gtk_printer_request_details would throw an exception in that case...
This part makes the dialog to show that the getting of details failed. If we don't move the gtk_printer_request_details() then the printer state "Getting printer information failed" (as set by processing of gtk_printer_request_details()) is overwritten by the "Getting printer information…" in the gtk_list_store_set() (cursor is also affected by the move).
Review of attachment 271909 [details] [review]: Ah, ok. Makes sense then
Thank you for the review. Can I commit the 2.24 version to gtk-2-24 branch and the master version to 3.10 too?
oh, dang I thought I had seen this on the 2.24 branch. Please go ahead. 3.10 too
Comment on attachment 271910 [details] [review] Fail nicely when /tmp is not writable (gtk 2.24) (In reply to comment #10) > oh, dang I thought I had seen this on the 2.24 branch. Please go ahead. 3.10 too Thank you. I've pushed it to gtk-2-24 and gtk-3-10.