GNOME Bugzilla – Bug 378764
gimp crashed to gtkfilechooser code
Last modified: 2007-07-01 22:42:19 UTC
That bug has been described on https://launchpad.net/distros/ubuntu/+source/gimp/+bug/73069 "To be honest, i dont know what happened, but it was reproducible. I am working with gimp and took a snapshot from another tool. After i finished with the picture and saved it to an .eps and .png I switched screens to import the stuff into my latex document. A few seconds later I got a message that gimp had crashed. This happened twice in a row. That is why I am posting this message. Attached to this bug report you will find the file created by the bug report tool of ubuntu/gnome. I called it "unexpected" because it didn't occur during interaction with gimp itself. cheers, josh http://librarian.launchpad.net/5153490/_usr_bin_gimp-2.2.1000.crash Attachment from /var/crash, generated by gnome/ubuntu crash tool ... libgtk2.0-0 2.10.6-0ubuntu1 ..." Debug backtrace:
+ Trace 88981
That might be similar to bug #363472
That Ubuntu bug describe an easy way to trigger the problem: https://launchpad.net/ubuntu/+source/gimp/+bug/82358 "I had a 'Save a copy' dialog open in GIMP. In nautilus, I renamed a file in this folder so I could reuse the name. When I returned to gimp, it crashed." Backtrace with GTK 2.10.9: Program received signal SIGSEGV, Segmentation fault.
+ Trace 106791
Thread NaN (LWP 17200)
From valgrind: ==17534== Address 0x7D57B49 is 1 bytes inside a block of size 128 free'd ==17534== at 0x4020F9A: free (vg_replace_malloc.c:233) ==17534== by 0x47DEF90: g_free (gmem.c:187) ==17534== by 0x4235016: gtk_file_info_free (gtkfilesystem.c:111) ==17534== by 0x423740F: file_model_node_free (gtkfilesystemmodel.c:1325) ==17534== by 0x42378AD: do_files_removed (gtkfilesystemmodel.c:1951) ==17534== by 0x477EF88: g_cclosure_marshal_VOID__POINTER (gmarshal.c:601) ==17534== by 0x477262A: g_closure_invoke (gclosure.c:490) ==17534== by 0x47830F2: signal_emit_unlocked_R (gsignal.c:2440) ==17534== by 0x4784616: g_signal_emit_valist (gsignal.c:2199) ==17534== by 0x4786D6D: g_signal_emit_by_name (gsignal.c:2267) ==17534== by 0x688AAEC: monitor_callback (gtkfilesystemgnomevfs.c:3500)
That one is the revelant one for the crasher rather: ==17534== Invalid read of size 1 ==17534== at 0x40222DE: strcmp (mc_replace_strmem.c:341) ==17534== by 0x421D008: name_sort_func (gtkfilechooserdefault.c:5607) ==17534== by 0x436402C: gtk_tree_model_sort_level_find_insert (gtktreemodelsort.c:1739) ==17534== by 0x43661E0: gtk_tree_model_sort_row_inserted (gtktreemodelsort.c:1787) ==17534== by 0x4283CAC: _gtk_marshal_VOID__BOXED_BOXED (gtkmarshalers.c:1346) ==17534== by 0x477262A: g_closure_invoke (gclosure.c:490) ==17534== by 0x47830F2: signal_emit_unlocked_R (gsignal.c:2440) ==17534== by 0x4784616: g_signal_emit_valist (gsignal.c:2199) ==17534== by 0x47847D8: g_signal_emit (gsignal.c:2243) ==17534== by 0x435CB98: gtk_tree_model_row_inserted (gtktreemodel.c:1496) ==17534== by 0x4238261: do_files_added (gtkfilesystemmodel.c:1755) ==17534== by 0x477EF88: g_cclosure_marshal_VOID__POINTER (gmarshal.c:601)
From gdb: (gdb) p *info_a Cannot access memory at address 0x2f6e6f69
More context from the valgrind backtrace would help find the cause of this.
what valgrind options do you recommend to use?
*** Bug 432192 has been marked as a duplicate of this bug. ***
Stacktrace in comment 1 exactly matches the stacktrace in bug 378126, which actually is a duplicate of bug 363472 according to bug 378126 comment 4. *** This bug has been marked as a duplicate of 363472 ***