! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Xfdesktop crashes after pressing f5 multiple times
Status:
RESOLVED: FIXED
Product:
Xfdesktop
Component:
General

Comments

Description Alexander Toresson 2007-01-23 20:55:18 CET
After pressing f5 multiple times on the desktop with file/launcher icons, xfdesktop (r24712) crashes. I've checked with gdb, and this does happen at a different place every time, so I suspect it's a memory access/management problem.

System: Debian Etch, Gtk 2.8.20, Glib 2.12.4
Comment 1 Brian J. Tarricone (not reading bugmail) 2007-01-23 21:19:26 CET
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)
Comment 2 Alexander Toresson 2007-01-24 15:47:23 CET
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.
Comment 3 Alexander Toresson 2007-01-24 15:48:33 CET
Created attachment 962 
text file with a few backtraces
Comment 4 Brian J. Tarricone (not reading bugmail) 2007-01-24 20:04:36 CET
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.)
Comment 5 Alexander Toresson 2007-01-24 20:32:12 CET
(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.
Comment 6 Brian J. Tarricone (not reading bugmail) 2007-02-25 11:26:18 CET
Can you still reproduce this with current trunk?  I have a feeling Benny might have fixed this in another bug.
Comment 7 Brian J. Tarricone (not reading bugmail) 2007-11-15 07:44:33 CET
Is this still reproducible with current trunk and/or 4.4 branch?
Comment 8 Brian J. Tarricone (not reading bugmail) 2009-08-22 09:53:20 CEST
No response in a couple years, can't reproduce this on 4.6.x anyway.

Bug #2806

Reported by:
Alexander Toresson
Reported on: 2007-01-23
Last modified on: 2009-08-22

People

Assignee:
Brian J. Tarricone (not reading bugmail)
CC List:
0 users

Version

Attachments

text file with a few backtraces (18.32 KB, text/plain)
2007-01-24 15:48 CET , Alexander Toresson
no flags

Additional information