This bug has been filed at Ubuntu Launchpad as https://bugs.launchpad.net/ubuntu/+source/xfce4-sensors-plugin/+bug/257656 Binary package hint: xfce4-sensors-plugin Whenever I want to reboot my laptop, I receive this message in the syslog: kernel: [181164.062102] xfce4-sensors-p[5964]: segfault at 08000000 eip b75e14c7 esp bfb570b8 error 4 uname -a Linux 2.6.24-20-generic #1 SMP Mon Jul 28 13:49:52 UTC 2008 i686 GNU/Linux (Running hardy-proposed) ProblemType: Crash Architecture: i386 Date: Wed Aug 13 13:24:34 2008 DistroRelease: Ubuntu 8.04 ExecutablePath: /usr/lib/xfce4-sensors-plugin/xfce4/panel-plugins/xfce4-sensors-plugin NonfreeKernelModules: ath_hal fglrxT Package: xfce4-sensors-plugin 0.10.99.4~svn-r3775-2 PackageArchitecture: i386 ProcCmdline: /usr/lib/xfce4-sensors-plugin/xfce4/panel-plugins/xfce4-sensors-plugin socket_id 14680131 name xfce4-sensors-plugin id 12175397282 display_name Sensor\ plugin size 34 screen_position 1 ProcEnviron: LC_TIME=en_DK.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=en_CA.UTF-8 SHELL=/bin/bash Signal: 11 SourcePackage: xfce4-sensors-plugin StacktraceTop: free () from /lib/tls/i686/cmov/libc.so.6 g_free () from /usr/lib/libglib-2.0.so.0 ?? () ?? () g_ptr_array_foreach () from /usr/lib/libglib-2.0.so.0 Title: xfce4-sensors-plugin crashed with SIGSEGV in free() Uname: Linux 2.6.24-20-generic i686 UserGroups: adm admin audio cdrom dialout dip fax floppy fuse lpadmin netdev plugdev powerdev sambashare scanner tape video Stacktrace and ThreadStacktrace are attached to the original bug report
(In reply to comment #0) Please specify the version number and distribution next time when submitting bug reports after reading the last bug reports -- it really makes life easier and eliminates some reports. The SIGSEGV *was* due to invalid string initialization and is removed long ago after Enrico's detailed bug report. Please try latest version and report errors on that one; I am not gonna fix 0.10.99.4 explicitly.
I am sorry. I will try to remember to be explicit in the future. The reporter is still experiencing this with 0.10.99.5~svn-r4998-2 xfce4-sensors-plugin using Ubuntu Intrepid Ibex version 8.10. Here is the latest comment: This bug DOES still occur with Intrepid, but now it's changed: Now two related programs crash - Dec 5 17:12:44 shuffles kernel: [154222.129185] xfce4-sensors-p[5453]: segfault at 8000000 ip b756042d sp bff0afa0 error 4 in libc-2.8.90.so[b74ef000+158000] Dec 5 17:12:44 shuffles kernel: [154222.494111] xfce4-places-pl[5447]: segfault at 656d696d ip b78eb5c8 sp bf85d050 error 4 in libgobject-2.0.so.0.1800.2[b78c2000+3c000] Thanks for your quick response.
Can you please try current svn and report if the problem still persists? AFAIR, I had a look over all allocation and free and applied according changes.
I am _not impressed_. To do a current svn build of xfce4-sensors-plugin, I needed to get the following packages from Pango because I couldn't find them anywhere else (and certainly not in the Ubuntu repo, where things can go five years without being added or updated): libxfce4mcs-4.4.3.tar.bz2 libxfce4util-4.4.3.tar.bz2 xfce4-panel-4.4.3.tar.bz2 libxfcegui4-4.4.3.tar.bz2 xfce-mcs-manager-4.4.3.tar.bz2 Everything seemed to have built and installed correctly, but now my XFCE configuration is trashed. Among other things, it's forgotten my UI preferences, desktop preferences, and all but one of the configuration manager items are missing. The sensors plugin is missing from my panel now. And when I try to re-add it, nothing happens and it seems to fail silently with nothing in /var/log/syslog.
(In reply to comment #4) > I am _not impressed_. To do a current svn build of xfce4-sensors-plugin, I > needed to get the following packages from Pango because I couldn't find them > anywhere else (and certainly not in the Ubuntu repo, where things can go five > years without being added or updated): > > libxfce4mcs-4.4.3.tar.bz2 > libxfce4util-4.4.3.tar.bz2 xfce4-panel-4.4.3.tar.bz2 > libxfcegui4-4.4.3.tar.bz2 xfce-mcs-manager-4.4.3.tar.bz2 Uhm, all the required packages are in the ubuntu repositories. They're the -dev packages, which are not installed by default. We are not impressed that you didn't ask for help before trying things which are not advisable. > Everything seemed to have built and installed correctly, but now my XFCE > configuration is trashed. Among other things, it's forgotten my UI preferences, > desktop preferences, and all but one of the configuration manager items are > missing. The sensors plugin is missing from my panel now. And when I try to > re-add it, nothing happens and it seems to fail silently with nothing in > /var/log/syslog. Chances are you did mess up your system. Generally you should not mix source installations with package installations, and my guess is you did not uninstall these Ubuntu packages before you ran 'make install', right?
> Uhm, all the required packages are in the ubuntu repositories. They're the -dev > packages, which are not installed by default. Well, I installed the dev packages from the repo and that didn't help. Installing the 4.4.3 packages from tars allowed it to build, at least. > Chances are you did mess up your system. Generally you should not mix source > installations with package installations, and my guess is you did not uninstall > these Ubuntu packages before you ran 'make install', right? Turns out my old system settings were preserved, the new xfce installation just wasn't looking for them. The old xfce in /usr/lib was being overridden by this new one in /usr/local/lib. make uninstall on the xfce prerequisites xfce-mcs-manager-4.4.3 and xfce4-panel-4.4.3 got me back to my old, working system. Even so, the sensors plugin still fails silently when I try to add it, and there's no uninstall make target. So. What would you have me do?
I am a Debian user, and I am experiencing the same bug as what is being reported in this thread. The previous version (0.10.99.5~svn-r4998-2) was working fine for me, but the most recent update in Debian Sid (0.10.99.6-1) caused the plugin to fail with a backtrace whenever I tried to add in to the panel, or whenever I login (if the plugin is already configured to open). My normal procedure would be to submit the bug report on the Debian BTS, and I did so, but it looks like the main Debian XFCE maintainer is gone for the next two weeks. I have come here hoping to save Yves-Alexis some trouble. I posted some backtrace info on the Debian BTS, and successfully used 'gdb' to get a better quality backtrace after being give some instruction by Yves-Alexis. After locating the line where the crash occurs, I investigated the source code and discovered that g_free() was often being run on an uninitialized variable. A full explanation can be read here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519181#msg45 Immediately following that post, I provided a patch that restores 0.10.99.6-1 to a working condition for me again. I doubt that code that I used for the fix is appropriate for the upstream source tree, so I was hoping that a developer here could 1) verify that my diagnosis is correct, and 2) produce code fix more appropriate than the one I'm using at the moment on my own system. HTH, and thanks for all the efforts of the XFCE developer team! Dave W.
Hey, well first of all, you could have tried to simply run the plain binary program xfce4-sensors which -- who would expect -- links to the very same library with al lthe hddtemp stuff inside. This executable could be seen in your installation logs etc. Anyway, you're right about what breaks it that uninitialized variables couldn't be free properly with *new* versions of gcc; I didn't have any problems earlier. Sorry to tell, moving variable declaration inside C code is *not* a solution because of 1) variables should be declared at the beginning 2) it would not resolve your issues when any of the mentioned else if branches would be entered. SVN will soon contain initialization to NULL which should work. Thanks to the guy that pointed that out and thanks to you for reporting and all the efforts you investigated when submitting the bugs at Debian. (In reply to comment #7)
(In reply to comment #8) > well first of all, you could have tried to simply run the plain binary program > xfce4-sensors which -- who would expect -- links to the very same library with > al lthe hddtemp stuff inside. This executable could be seen in your > installation logs etc. You overlooked a couple of factors in your hurry to be sarcastic: 1) When first investigating the crash, it was possible that parameters were being passed to the plugin that were causing it to die. Debugging it by directly running the plugin binary would never have caught such a problem. (Of course, in hindsight, we _now_ know that your approach would have worked.) 2) I have never looked at XFCE code before, much less tried to debug a crashing plugin using 'gdb'. I know you didn't have time to read that whole thread on the Debian BTS, but if you _had_, you would have seen that I asked the Debian maintainer for guidance on how to proceed... and was directed to this information on the xfce.org website: http://wiki.xfce.org/howto/panel_plugin_debug "Who would expect" that the xfce.org website would provide debugging advice that would cause XFCE developers to mock people who use it to try to provide fixes for their broken code? If you think those instructions are incorrect, you might consider going there and making the necessary changes. > Anyway, you're right about what breaks it that uninitialized variables > couldn't be free properly with *new* versions of gcc; I didn't have any > problems earlier. Well, I wouldn't fault 'gcc'. I found the problem by comparing the working version to the new version, with the addition of the new code involving "checktext". By declaring the variable at the top of the function, and freeing it near the end, the developer who introduced these changes made it possible to easily overlook that fact that not all code paths initialize the variable. > Sorry to tell, moving variable declaration inside C code is *not* a solution > because of 1) variables should be declared at the beginning Well, I guess someone needs to explain that to my compiler... since the changes I made work fine right now. You cannot seriously be arguing that variables _have_ to be declared at the beginning of a function, since the C language allows any "compound statement" (a block of code enclosed in braces) to begin with an (optional) declaration list. The GNU C Reference puts it this way: "You can declare variables inside a block; such variables are local to that block." http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Blocks A more official language reference puts it more tersely: http://techpubs.sgi.com/library/dynaweb_docs/0650/SGI_Developer/books/CLanguageRef/sgi_html/ch08.html#Z86421 > 2) it would not resolve your issues when any of the mentioned else if > branches would be entered. I used the approach of moving both the declarations of "checktext" and the corresponding call of g_free(checktext) into the blocks where "checktext" was actually being used. If you look carefully at the if-else structure in get_hddtemp_value(), you will see that only two blocks even need "checktext" at all, so there is no point for "checktext" to exist anywhere else in the code _except_ in those two blocks. It was the fact that "checktext" was freed _outside_ of those blocks that introduced the bug. Not being familiar with g_free(), I was not sure if merely initializing it to NULL would be a correct solution. OTOH, I _was_ sure that limiting the scope of "checktext" to only those blocks where it was needed, and freeing it in those blocks, was guaranteed to be a workable solution. (Assuming no other bugs were present besides this one.) > SVN will soon contain initialization to NULL which should work. Thanks to the > guy that pointed that out and thanks to you for reporting and all the efforts > you investigated when submitting the bugs at Debian. Well, thank you for applying a fix for the problem... and sorry to have distressed anyone because of my lack of familiarity with debugging XFCE plugins, with debugging in general, and with my lack of familiarity with the behavior of library functions such as g_free() so that I proposed the sort of scope usage that would have made this bug impossible in the first place! In the future, I'll make sure I read the XFCE wiki first so that I don't make a fool.... Oh, never mind! ;) Sincere gratitude for XFCE and its development team! Dave W.
NULL initialization seems to have fixed these bugs or they are no longer an issue for whatever reason or they are related to 6118.