User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/2.0.0.8 Build Identifier: Trying to open "Desktop Settings," whether from Xfce menu, or Settings Manger, or wherever, causes xfce-mcs-manager to seg fault. AFAIK opening any other settings window is successful. Stack trace attached. Reproducible: Always Steps to Reproduce: 1. Attempt to open Desktop Settings 2. 3. Actual Results: xfce-mcs-manager crashes Expected Results: open Desktop Settings window
Created attachment 1445 gdb stack trace
This is probably me... Reporter: can you build both libxfce4util and xfdesktop with --enable-debug=yes and get a new stacktrace? Also, at the point of the crash, can you type 'up', followed by 'info locals' and then 'info args' and post that output as well?
(In reply to comment #2) Well, rebuilding those made the bug go away. I did have to install a couple -dev packages in order to build; I don't know if those had anything to do with it. Also, when trying to build xfdesktop, I got these error messages: Making all in po make[2]: Entering directory `/home/sdexter/xfdesktop4-4.4.1/po' file=`echo ar | sed 's,.*/,,'`.gmo \ && rm -f $file && -o $file ar.po /bin/sh: -o: not found make[2]: *** [ar.gmo] Error 127 make[2]: Leaving directory `/home/sdexter/xfdesktop4-4.4.1/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sdexter/xfdesktop4-4.4.1' make: *** [all] Error 2 Looking in po/Makefile, I realized this was because the GMSGFMT variable was empty. Following advice here http://mail.gnome.org/archives/orca-list/2007-March/msg00345.html I installed the (debian) gettext package, and the build was successful. I don't know if it's worth adding a check for that in configure...? > This is probably me... > > Reporter: can you build both libxfce4util and xfdesktop with --enable-debug=yes > and get a new stacktrace? > > Also, at the point of the crash, can you type 'up', followed by 'info locals' > and then 'info args' and post that output as well? >
(In reply to comment #3) > > Well, rebuilding those made the bug go away. I did have to install a couple > -dev packages in order to build; I don't know if those had anything to do with > it. Aww, man, I hate it when that happens. It's possible that some extra checks are done in the debug build. Can you kill xfce-mcs-manager, and then run it from a terminal (with xfce-mcs-manager --no-daemon-debug), and then open the Desktop Settings dialog and see if there's any console output? > Also, when trying to build xfdesktop, I got these error messages: > > Making all in po > make[2]: Entering directory `/home/sdexter/xfdesktop4-4.4.1/po' > file=`echo ar | sed 's,.*/,,'`.gmo \ > && rm -f $file && -o $file ar.po > /bin/sh: -o: not found > make[2]: *** [ar.gmo] Error 127 > make[2]: Leaving directory `/home/sdexter/xfdesktop4-4.4.1/po' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/sdexter/xfdesktop4-4.4.1' > make: *** [all] Error 2 > > Looking in po/Makefile, I realized this was because the GMSGFMT variable was > empty. Following advice here > http://mail.gnome.org/archives/orca-list/2007-March/msg00345.html I installed > the (debian) gettext package, and the build was successful. I don't know if > it's worth adding a check for that in configure...? Yeah, probably -- older versions of the configure/automake magic used to distribute the .gmo files in the tarball; at some point that changed, not sure why. It's odd that configure doesn't check for it, but yeah, we should do that.
(In reply to comment #4) Here's the console output: (xfce-mcs-manager:508): libxfce4util-CRITICAL **: xfce_rc_set_group: assertion `rc != NULL' failed (xfce-mcs-manager:508): libxfce4util-CRITICAL **: xfce_rc_read_entry: assertion `rc != NULL' failed (xfce-mcs-manager:508): libxfce4util-CRITICAL **: xfce_rc_read_entry: assertion `rc != NULL' failed (xfce-mcs-manager:508): libxfce4util-CRITICAL **: xfce_rc_read_entry: assertion `rc != NULL' failed (xfce-mcs-manager:508): libxfce4util-CRITICAL **: xfce_rc_read_entry: assertion `rc != NULL' failed (xfce-mcs-manager:508): libxfce4util-CRITICAL **: xfce_rc_close: assertion `rc != NULL' failed Looks like -something- interesting is happening -- let me know what else I can do. > (In reply to comment #3) > > > > Well, rebuilding those made the bug go away. I did have to install a couple > > -dev packages in order to build; I don't know if those had anything to do with > > it. > > Aww, man, I hate it when that happens. It's possible that some extra checks > are done in the debug build. Can you kill xfce-mcs-manager, and then run it > from a terminal (with xfce-mcs-manager --no-daemon-debug), and then open the > Desktop Settings dialog and see if there's any console output? > > > Also, when trying to build xfdesktop, I got these error messages: > > > > Making all in po > > make[2]: Entering directory `/home/sdexter/xfdesktop4-4.4.1/po' > > file=`echo ar | sed 's,.*/,,'`.gmo \ > > && rm -f $file && -o $file ar.po > > /bin/sh: -o: not found > > make[2]: *** [ar.gmo] Error 127 > > make[2]: Leaving directory `/home/sdexter/xfdesktop4-4.4.1/po' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/sdexter/xfdesktop4-4.4.1' > > make: *** [all] Error 2 > > > > Looking in po/Makefile, I realized this was because the GMSGFMT variable was > > empty. Following advice here > > http://mail.gnome.org/archives/orca-list/2007-March/msg00345.html I installed > > the (debian) gettext package, and the build was successful. I don't know if > > it's worth adding a check for that in configure...? > > Yeah, probably -- older versions of the configure/automake magic used to > distribute the .gmo files in the tarball; at some point that changed, not sure > why. It's odd that configure doesn't check for it, but yeah, we should do > that. >
This isn't our bug. It's due to an Ubuntu-specific patch. See here: http://patches.ubuntu.com/by-release/ubuntu/x/xfdesktop4/xfdesktop4_4.4.2-1ubuntu1.patch That code does not exist in our sources. In the future, please report bugs to your distro first; they'll push it to us if it's not their problem. On a side note, they could also avoid these crashes by NOT compiling our sources with G_DISABLE_CHECKS. That's definitely a bad idea.