GNOME Bugzilla – Bug 491775
Crash trying to print to a file from dialog
Last modified: 2007-11-02 15:38:38 UTC
Version: 1.7.13 What were you doing when the application crashed? Trying to print to a file. This worked before, however, I had just changed the orientation of the paper (under page setup). Preview worked. Distribution: Slackware Slackware 11.0.0 Gnome Release: 2.20.1 2007-10-15 (GARNOME) BugBuddy Version: 2.20.1 System: Linux 2.6.23.1 #71 SMP Sat Oct 13 20:31:02 EDT 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 60900000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: gnome Memory status: size: 139862016 vsize: 139862016 resident: 37441536 share: 25403392 rss: 37441536 rss_rlim: 4294967295 CPU usage: start_time: 1193758165 rtime: 1725 utime: 1654 stime: 71 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/opt/gnome/bin/gnumeric' Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb69d86c0 (LWP 8794)] 0xb6c37071 in waitpid () from /lib/tls/libpthread.so.0
+ Trace 173955
Thread 1 (Thread 0xb69d86c0 (LWP 8794))
----------- .xsession-errors (313952266 sec old) --------------------- iceauth: creating new authority file /home/ronis/.ICEauthority --------------------------------------------------
You are saying preview worked but printing crashed? As far as Gnumeric is concerned that is the same code. Can you replicate that crash with your file? If you can would it be possible to obtain a copy of that file?
I think there is a fair chance that this is a dupe of bug 478552, i.e., memory got corrupted and things went downhill from there.
Assuming that cp_gtk_page_setup I don't see ay evidence of memory corruption, ie. the backtrace looks reasonable, and since the crash happens inside gtk_page_setup_get_paper_size this may do different things depending on printers (ie. also between printing to pdf and printing to a real printer). Of course this would put this into gtk land.
Referring to comment #1, yes that's what I'm saying. I had printed the file, decided to change the orientation, previewed it and then tried to print. (I don't remember if I hit print from withing the preview dialog or not, perhaps this is obvious from the backtrace).
I think I'm seeing a similar crash with trunk (r16045). Steps to reproduce: - Run Gnumeric - File > Print - Select the PDF printer and press the Print button (Range: 1, Copies: 1, Reverse: unchecked) - File > Page Setup - Press the Print button to crash Gnumeric Backtrace: Program received signal SIGSEGV, Segmentation fault.
+ Trace 174404
Thread NaN (LWP 7858)
I seem to be able to replicate David's crash in gnm_request_page_setup_cb using sum1's instructions.
Hmmm... Seems that my last comment never made it here. I too have been able to reproduce the crash following sum1's instruction. One small difference, is that bug-buddy wasn't able to get a backtrace this time on my machine. I rebuilt all of garnome yesterday (including gnumeric/goffice), but the compile flags were identical to what I used for the version which crashed initially.
There are several issues: sum1: your crash may arise from the fact that you are printing an empty file. gtk+ can't handle printing 0 pages. An earlier fix for this unfortunately simply passed a page number of 1 to gtk which then crashes as a pagesetup for that page is being retrieved. I have a fix for this in my tree, I will commit later today. There is a gtk bug that causes gtk to try to retrieve pagesetups for non-existing pages. I will commit a work around later today. David: I suspect that you fell prey to the gtk bug. David: Can you replicate your crash with your file?
Hi Andreas, Perphaps I wasn't clear enough. I followed sum1's instructions with my file. After the 1st print the sheet printed . Note that I don't have a "PDF" printer, I used my default printer under CUPS (a postscript printer). I then went to File -> Page Setup and pressed print as per the instruction. I crashed, although no traceback was generated (see my preceding comment). I can give you a copy of the file, although I'd rather not post it as it contains minimally sensitive data from my job. David
David: sorry I misunderstood. I have include some more tests to avoid any crashes for unexpected calls. So either Morten is right that this is the result of a prior memory corruption (bug 478552) or my changes that I just committed should remove these crashes. David, would you be able to pull an up-to-date svn tree and recompile to see whether your file is still crashing? You need revision 16053 or later. Alternatively, or if your crash is still happening it would be great if you could mail me that file. I would follow our confidentiality procedure, ie. I am the only one to see the file and would delete it upon fixing the crash (or if I fail to replicate it even with your file.) Thank you for your help.
Unfortunately, I still get a crash with the steps from comment 5 with r16053 (even after a make clean). Valgrind output: ** (lt-gnumeric:31273): WARNING **: Working around gtk+ bug 423484. ** (lt-gnumeric:31273): WARNING **: Down and across requested, but printing across then down. ==31273== ==31273== Invalid read of size 4 ==31273== at 0x41CB7B0: cb_do_print (dialog-printer-setup.c:1705) ==31273== by 0x4C79C08: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C6C771: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C7D322: (within /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C7E846: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C7EA08: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4810056: gtk_button_clicked (gtkbutton.c:889) ==31273== by 0x4811C8D: gtk_real_button_released (gtkbutton.c:1484) ==31273== by 0x4C79C08: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C6AF88: (within /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C6C771: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C7D7B9: (within /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== Address 0xBBE361C is 4 bytes inside a block of size 452 free'd ==31273== at 0x402237F: free (vg_replace_malloc.c:233) ==31273== by 0x4CD4960: g_free (in /usr/lib/libglib-2.0.so.0.1400.1) ==31273== by 0x41CB83C: cb_do_print_destroy (dialog-printer-setup.c:1727) ==31273== by 0x4CB9487: g_datalist_clear (in /usr/lib/libglib-2.0.so.0.1400.1) ==31273== by 0x4C70D3F: (within /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4909BEB: gtk_object_finalize (gtkobject.c:447) ==31273== by 0x4A07244: gtk_widget_finalize (gtkwidget.c:7908) ==31273== by 0x4A200FE: gtk_window_finalize (gtkwindow.c:4228) ==31273== by 0x4C6EAEB: g_object_unref (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C6EE37: g_object_run_dispose (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4909974: gtk_object_destroy (gtkobject.c:403) ==31273== by 0x4A0F674: gtk_widget_destroy (gtkwidget.c:2886) ==31273== ==31273== Invalid read of size 4 ==31273== at 0x41CB7BD: cb_do_print (dialog-printer-setup.c:1705) ==31273== by 0x4C79C08: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C6C771: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C7D322: (within /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C7E846: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C7EA08: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4810056: gtk_button_clicked (gtkbutton.c:889) ==31273== by 0x4811C8D: gtk_real_button_released (gtkbutton.c:1484) ==31273== by 0x4C79C08: g_cclosure_marshal_VOID__VOID (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C6AF88: (within /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C6C771: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C7D7B9: (within /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== Address 0xBBE3618 is 0 bytes inside a block of size 452 free'd ==31273== at 0x402237F: free (vg_replace_malloc.c:233) ==31273== by 0x4CD4960: g_free (in /usr/lib/libglib-2.0.so.0.1400.1) ==31273== by 0x41CB83C: cb_do_print_destroy (dialog-printer-setup.c:1727) ==31273== by 0x4CB9487: g_datalist_clear (in /usr/lib/libglib-2.0.so.0.1400.1) ==31273== by 0x4C70D3F: (within /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4909BEB: gtk_object_finalize (gtkobject.c:447) ==31273== by 0x4A07244: gtk_widget_finalize (gtkwidget.c:7908) ==31273== by 0x4A200FE: gtk_window_finalize (gtkwindow.c:4228) ==31273== by 0x4C6EAEB: g_object_unref (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4C6EE37: g_object_run_dispose (in /usr/lib/libgobject-2.0.so.0.1400.1) ==31273== by 0x4909974: gtk_object_destroy (gtkobject.c:403) ==31273== by 0x4A0F674: gtk_widget_destroy (gtkwidget.c:2886)
sum1: thanks, the valgrind output was _very_ helpful. It is pretty clear what the problem is. I will commit the fix later today. I had missed that you used the print button in the page setup dialog, and was able to create a similar crash from within the print dialog. Hint to self: it's a pretty bad idea to delete a data structure before using it! :-)
sum1: your crash should now be really fixed. revision 16056
That looks like a very likely cause of the crash. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
I have tested my fix also with David's file and cannot replicate the crash anymore. So I hope it is indeed fixed. THanks to David for providing his file for testing. It has been deleted.