I ran valgrind on gthumb and came across this oddity:

==12062== Source and destination overlap in strncpy(0x26efe04d, 0x26efe04d, 125)
==12062== at 0x4C2C236: strncpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12062== by 0x730A0BD: g_utf8_strncpy (string3.h:121)
==12062== by 0x46EDB1: gth_file_properties_real_set_file (gth-file-properties.c:130)
==12062== by 0x4AB3F6: gth_property_view_set_file (gth-sidebar.c:323)
==12062== by 0x4AABC1: _gth_sidebar_update_current_child (gth-sidebar.c:92)
==12062== by 0x7058E71: g_closure_invoke (gclosure.c:777)
==12062== by 0x706A942: signal_emit_unlocked_R (gsignal.c:3547)
==12062== by 0x707322F: g_signal_emit_valist (gsignal.c:3296)
==12062== by 0x7073471: g_signal_emit (gsignal.c:3352)
==12062== by 0x54E032D: gtk_widget_map (gtkwidget.c:3412)
==12062== by 0x53E2B67: gtk_notebook_map (gtknotebook.c:1784)
==12062== by 0x7059099: _g_closure_invoke_va (gclosure.c:840)
==12062==

gthumb/gth-file-properties.c:130

                g_utf8_strncpy (value, value, MAX_ATTRIBUTE_LENGTH - 3);

Note same src and dst address. This results in unspecified behaviour in the C library, see Valgrind manual 5.3.6 Overlapping source and destination blocks @ http://www.network-theory.co.uk/docs/valgrind/valgrind_49.html