I can't reproduce this here... can you try setting the env var G_DEBUG=fatal_warnings and try running through gdb again?  It should abort() the first time the error actually occurs.

Just for my reference, original output/bt is:

** (xfdesktop:28805): CRITICAL **: xfdesktop_file_icon_peek_info: assertion
`XFDESKTOP_IS_FILE_ICON(icon)' failed

(xfdesktop:28805): GLib-GObject-WARNING **: invalid uninstantiatable type
`XfdesktopRegularFileIcon' in cast to `GObject'

(xfdesktop:28805): GLib-GObject-CRITICAL **: g_object_unref: assertion
`G_IS_OBJECT (object)' failed

(xfdesktop:28805): GLib-GObject-CRITICAL **: g_object_new: assertion
`G_TYPE_IS_OBJECT (object_type)' failed

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1488329024 (LWP 28805)]
xfdesktop_regular_file_icon_new (info=0xa5c04a40, screen=0x80950f0)
    at xfdesktop-regular-file-icon.c:636
636         regular_file_icon->priv->info = thunar_vfs_info_ref(info);
(gdb) bt
#0  xfdesktop_regular_file_icon_new (info=0xa5c04a40, screen=0x80950f0)
    at xfdesktop-regular-file-icon.c:636
#1  0x0806a8f8 in xfdesktop_file_icon_manager_add_regular_icon (
    fmanager=0x8099de8, info=0x0, defer_if_missing=1)
    at xfdesktop-file-icon-manager.c:2161
#2  0x0806a9ee in xfdesktop_file_icon_manager_listdir_infos_ready_cb (
    job=0x81d2b48, infos=0x8290d10, user_data=0x8099de8)
    at xfdesktop-file-icon-manager.c:2477
#3  0xa7e5ec42 in _thunar_vfs_marshal_BOOLEAN__POINTER (closure=0x82689e8,
    return_value=0xafad8f50, n_param_values=2, param_values=0xafad902c,
    invocation_hint=0xafad8f3c, marshal_data=0x806a9a0)
    at thunar-vfs-marshal.c:82
#4  0xa781098b in IA__g_closure_invoke (closure=0x82689e8,
    return_value=0xafad8f50, n_param_values=2, param_values=0xafad902c,
    invocation_hint=0xafad8f3c) at gclosure.c:490
#5  0xa7820f2d in signal_emit_unlocked_R (node=0x80dc968, detail=0,
    instance=0x81d2b48, emission_return=0xafad91ec,
    instance_and_params=0xafad902c) at gsignal.c:2440
#6  0xa7822208 in IA__g_signal_emit_valist (instance=0x81d2b48, signal_id=113,
    detail=0, var_args=0xa4ce4340 "PCΤ") at gsignal.c:2209
#7  0xa7e68c75 in thunar_vfs_job_source_dispatch (source=0x82a4388,
    callback=0, user_data=0x0) at thunar-vfs-job.c:471
#8  0xa774c731 in IA__g_main_context_dispatch (context=0x8099738)
    at gmain.c:2045
#9  0xa774f7a6 in g_main_context_iterate (context=0x8099738, block=1,
    dispatch=1, self=0x807e048) at gmain.c:2677
#10 0xa774fb67 in IA__g_main_loop_run (loop=0x8213090) at gmain.c:2881
#11 0xa7c2f281 in IA__gtk_main () at gtkmain.c:1003
#12 0x0805591c in main (argc=Cannot access memory at address 0x0
) at main.c:394
(gdb)

I suspect the backtrace and this error might have nothing to do with the actual error, as most times I run it I get a completely different backtrace. I've attached a text file with some backtraces that I gathered this afternoon. I haven't been able to get the same backtrace as the one above again.

Created attachment 962 
text file with a few backtraces

Did you set G_DEBUG=fatal_warnings?  Also setting MALLOC_CHECK_=2 (if you're on Linux, and yes, the trailing underscore is correct) can be useful as well.

The other option is to run it through valgrind and look for memory read errors and fun stuff like that.  (You can turn off leak checking to make the output a little less noisy.)

(In reply to comment #4)
> Did you set G_DEBUG=fatal_warnings?

I didn't, as I never got any glib warnings today...

> Also setting MALLOC_CHECK_=2 (if you're on
> Linux, and yes, the trailing underscore is correct) can be useful as well.

Yes, if I manage to repeat the case where I got a glibc warning.

> The other option is to run it through valgrind and look for memory read errors
> and fun stuff like that.  (You can turn off leak checking to make the output a
> little less noisy.)
> 

I did try running it through valgrind, but never actually managed to make the program crash while running under valgrind. But I'll try again.

Can you still reproduce this with current trunk?  I have a feeling Benny might have fixed this in another bug.

Is this still reproducible with current trunk and/or 4.4 branch?

No response in a couple years, can't reproduce this on 4.6.x anyway.