! 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 !
xfconfd segfaults at startup on amd64
Status:
RESOLVED: FIXED

Comments

Description Landry Breuil editbugs 2009-01-31 10:56:15 CET
I'm kinda puzzled here, backends contains a value for key xfce-perchannel-xml, but to me backend_gtype gets assigned a weird value.
The GPOINTER_TO_UINT/GINT_TO_GPOINTER dance seems strange to me, and according to the doc this could be the culprit : 'Remember, YOU MAY NOT STORE POINTERS IN INTEGERS. THIS IS NOT PORTABLE IN ANY WAY SHAPE OR FORM. These macros ONLY allow storing integers in pointers, and only preserve 32 bits of the integer; values outside the range of a 32-bit integer will be mangled.'

Will try to add some debug info tomorrow.

Here's the backtrace :

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 8350, thread 0x204e95800]
0x000000020773d037 in g_type_fundamental () from /usr/local/lib/libgobject-2.0.so.1800.1
(gdb) bt full
#0  0x000000020773d037 in g_type_fundamental () from /usr/local/lib/libgobject-2.0.so.1800.1
No symbol table info available.
#1  0x0000000207726305 in g_object_new () from /usr/local/lib/libgobject-2.0.so.1800.1
No symbol table info available.
#2  0x000000000040573c in xfconf_backend_factory_get_backend (type=0x203fef1a0 "xfce-perchannel-xml", error=0x7f7ffffc6bc0) at xfconf-backend-factory.c:76
        backend = (XfconfBackend *) 0x20cf2a5a0
        backend_gtype = 221961728
#3  0x0000000000407426 in xfconf_daemon_load_config (xfconfd=0x2056f1000, backend_ids=0x20cf2a5a0, error=0x7f7ffffc6c38) at xfconf-daemon.c:478
        error1 = (GError *) 0x0
        backend = (XfconfBackend *) 0x20cf2a5a0
        i = 0
#4  0x0000000000407620 in xfconf_daemon_new_unique (backend_ids=0x20cf2a5a0, error=0x7f7ffffc6c38) at xfconf-daemon.c:543
        xfconfd = (XfconfDaemon *) 0x2056f1000
#5  0x0000000000405525 in main (argc=1, argv=0x7f7ffffc6d40) at main.c:204
        mloop = (GMainLoop *) 0x20cf2a6f0
        xfconfd = (XfconfDaemon *) 0x20599b980
        error = (GError *) 0x0
        act = {__sigaction_u = {__sa_handler = 0x1, __sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}
        signal_io = (GIOChannel *) 0x20599b980
        signal_watch = 1
        opt_ctx = (GOptionContext *) 0x20599b980
        backends = (gchar **) 0x20cf2a5a0
        print_version = 0
        options = {{long_name = 0x50bea0 "version", short_name = 86 'V', flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0x7f7ffffc6c4c, 
    description = 0x50bea8 "Prints the xfconfd version.", arg_description = 0x0}, {long_name = 0x50bec4 "backends", short_name = 98 'b', flags = 0, 
    arg = G_OPTION_ARG_STRING_ARRAY, arg_data = 0x7f7ffffc6c40, 
    description = 0x50bfa0 "Configuration backends to use.  The first backend specified is opened read/write; the others, read-only.", arg_description = 0x0}, {long_name = 0x0, 
    short_name = 0 '\0', flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0x0, description = 0x0, arg_description = 0x0}}
Comment 1 Landry Breuil editbugs 2009-01-31 11:15:51 CET
As a sidenote, removing both casts make the compiler complain indeed :
xfconf-backend-factory.c: In function `xfconf_backend_factory_ensure_backends':
xfconf-backend-factory.c:52: warning: passing arg 3 of `g_hash_table_insert' makes pointer from integer without a cast
xfconf-backend-factory.c: In function `xfconf_backend_factory_get_backend':
xfconf-backend-factory.c:66: warning: assignment makes integer from pointer without a cast

but xfconfd doesn't segfault anymore at startup, and i can launch a session in Xnest. (well i have other issues afterwards with xfwm4/xfconf, but don't seem related to this one..)
Comment 2 Landry Breuil editbugs 2009-02-01 15:30:56 CET
I have to admit i'm a bit lost with all those casts.. i added debugging code in
xfconf_backend_factory_get_backend() and xfconf_backend_factory_ensure_backends(), and the value returned by g_hash_table_lookup() is the value added in the hashtable.. but the type is weird. according to the doc, it returns a gpointer/void*, but gdb tells me it's an integer :

(gdb) whatis g_hash_table_lookup(backends, type)
type = int

We store a GType (casted to gpointer) in the hashtable, which according to the docs/headers should be gsize/unsigned int (so the cast seems correct)

(gdb) whatis xfconf_backend_perchannel_xml_get_type()
type = GType

This crash really puzzles me.. i'm open to all kind of debugging ideas. Removing those casts solves the issue for me, but it's definitely not what we want.
Comment 3 Stephan Arts editbugs 2009-02-01 21:16:24 CET
Created attachment 2140 
Replaces GPOINTER_TO_GUINT by GPOINTER_TO_GSIZE (might have an impact on 64bit systems)

A GType is a typedef-ed gsize, a gsize might not be an unsigned-int on 64bit systems, making GUINT_TO_POINTER and GPOINTER_TO_UINT break.

Please try this patch, and see if it helps.
Comment 4 Landry Breuil editbugs 2009-02-01 21:37:21 CET
Thanks, fixes the issue on amd64. I should have catched that macro existed..
Comment 5 Stephan Arts editbugs 2009-02-01 21:48:36 CET
Tested on 32bit Intel, no regressions there.

Committed in revision 29426
Comment 6 Brian J. Tarricone (not reading bugmail) 2009-02-02 05:59:03 CET
No, I don't like this fix.  Assuming sizeof(GType) == sizeof(gsize) is just as bad as what I was doing (when you compile a C++ program that uses gobject, a GType is an gulong, which should be the same size a a gulong, but I don't think anyone's verified this).  Since we know a GType will always fit in a pointer, we should just be casting manually and not using the macros.

Actually, to be completely safe, I'm just gonna malloc a new GType and store the pointer in the hash table.  I don't mind a one-time 4- or 8-byte loss.

Please run these sorts of things by me before committing.

Checked in.

Bug #4881

Reported by:
Landry Breuil
Reported on: 2009-01-31
Last modified on: 2015-02-16

People

Assignee:
Stephan Arts
CC List:
1 user

Version

Version:
Unspecified

Attachments

Additional information