Created attachment 870306 [details] tar bz2 of the source Description of problem: I am running on Fedora 20 with the mate desktop. I wrote my own brightness and mail check panel applets. I install the brightness applet into /usr/libexec/mate-applets/backlight_applet2 I also install the corresponding files /usr/share/glib-2.0/schemas/org.mate.panel.applet.backlight.gschema.xml /usr/share/mate-panel/applets/org.mate.applets.BacklightApplet.mate-panel-applet /usr/share/dbus-1/services/org.mate.panel.applet.BacklightAppletFactory.service I attached a tar of the source. In any case, it usually works, but sometimes when I boot, I get a message that the applet crashed, and when I look at /usr/libexec/mate-applets/backlight_applet2, it is larger than the file that I installed. I ran "strings" on the executable in /usr/libexec/mate-applets and on the executable in my development area, and the one in /usr/libexec/mate-applets had an additional list of shared libraries. Is some other process like "prelink" trying to process my executable? Do I need to install my executable under /usr/local instead? I ran 'yum provides /usr/libexec/mate-applets/backlight_applet2' to check that no other package uses this file. Version-Release number of selected component (if applicable): kernel-3.13.5-200.fc20.x86_64 mate-common-1.6.2-1.fc20.noarch mate-desktop-devel-1.6.2-1.fc20.x86_64 mate-panel-devel-1.6.2-1.fc20.x86_64 gcc-4.8.2-7.fc20.x86_64 libgcc-4.8.2-7.fc20.x86_64 gcc-c++-4.8.2-7.fc20.x86_64 How reproducible: I notice the problem after booting once every few days. Steps to Reproduce: 1. build and install the applet 2. use the system a few days, installing system updates as they are available 3. Actual results: Something changes the executables in /usr/libexec/mate-applets/ Expected results: The executables stay identical to what was installed. Additional info:
It could be prelink
It happened again when I booted and logged in this morning. Mate immediately said that my backlight applet crashed, and reloading didn't help, so I removed it. Then I reran the "make install" in my development area, added it back to the panel, and it is working now. I looked at the bad executable in more detail, and I think that prelink modified it. How does prelink break it? Did I build the applet incorrectly? I use the Makefile line gcc `pkg-config --cflags --libs libmatepanelapplet-4.0` `pkg-config --cflags --libs dbus-glib-1` -Wall -o $(NAME) $(NAME).c If I install it under /usr/local, will that keep it away from prelink? /etc/prelink.conf and /etc/prelink.conf.d/* do not list anything under /usr/local. I saved the broken modified version from /usr/libexec/mate-applets and the good version from my development area. -r-xr-xr-x 1 william william 51044 Mar 4 14:57 backlight-modified -rwxrwxrwx 1 william william 35172 Mar 4 14:57 backlight-orig $ size backlight-* text data bss dec hex filename 34714 1776 0 36490 8e8a backlight-modified 19793 1504 272 21569 5441 backlight-orig $ strings -10 < backlight-modified | sort > strings-modified $ strings -10 < backlight-orig | sort > strings-orig $ ls -l strings-modified strings-orig -rw-rw-rw- 1 william william 7488 Mar 4 15:04 strings-modified -rw-rw-rw- 1 william william 6758 Mar 4 15:04 strings-orig $ diff strings-modified strings-orig | head 8,10d7 < .gnu.conflict < .gnu.liblist < .gnu.prelink_undo <-- I think that this means that prelink made the changes 17d13 < /lib64/ld-linux-x86-64.so.2 253,267d248 < libEGL.so.1 < libGL.so.1 < libX11-xcb.so.1 $ ldd backlight-modified | wc 65 257 4128 $ ldd backlight-orig | wc 65 257 4128 William
> I wrote my own brightness and mail check panel applets. Have you looked at mate-university? > I install the brightness applet into > /usr/libexec/mate-applets/backlight_applet2 > I also install the corresponding files > /usr/share/glib-2.0/schemas/org.mate.panel.applet.backlight.gschema.xml > /usr/share/mate-panel/applets/org.mate.applets.BacklightApplet.mate-panel- > applet > /usr/share/dbus-1/services/org.mate.panel.applet.BacklightAppletFactory. > service > I attached a tar of the source. > > In any case, it usually works, but sometimes when I boot, I get a message > that the applet crashed, and when I look at > /usr/libexec/mate-applets/backlight_applet2, it is larger than the file that > I installed. I ran "strings" on the executable in /usr/libexec/mate-applets > and on the executable in my development area, and the one in > /usr/libexec/mate-applets had an additional list of shared libraries. > Is some other process like "prelink" trying to process my executable? > Do I need to install my executable under /usr/local instead? > I ran 'yum provides /usr/libexec/mate-applets/backlight_applet2' to check > that no other package uses this file. I would recommend that you visit us in #mate-dev on IRC and discuss with Stefano he would know better than all of us.
Thanks, I hadn't seen the mate-university applet. I wrote the applets in 2010 for gnome2 using https://projects.gnome.org/ORBit2/appletstutorial.html I converted them to mate 1.4 in 2012 with the migrate.sh script from Perberos. I converted them to mate 1.6 last week by reading the geyes code in mate-applets and looking at the dbus usage in mate-power-manager. I think that I found the problem. I rebuilt with -g, ran prelink on it, ran the applet in an xterm under valgrind, and then added it to the panel. valgrind caught the bad access. I needed to set gerror to NULL before calling dbus_g_bus_get(DBUS_BUS_SESSION, &gerror). William
(In reply to William Bader from comment #4) > Thanks, I hadn't seen the mate-university applet. > > I wrote the applets in 2010 for gnome2 using > https://projects.gnome.org/ORBit2/appletstutorial.html > I converted them to mate 1.4 in 2012 with the migrate.sh script from > Perberos. > I converted them to mate 1.6 last week by reading the geyes code in > mate-applets and looking at the dbus usage in mate-power-manager. > > I think that I found the problem. I rebuilt with -g, ran prelink on it, ran > the applet in an xterm under valgrind, and then added it to the panel. > valgrind caught the bad access. I needed to set gerror to NULL before > calling dbus_g_bus_get(DBUS_BUS_SESSION, &gerror). > > William Glad to hear you got it resolved. The invitation to #mate-dev on freenode remains open. Would love to get your applets merged upstream. :)
If it isn't solved please ask directly mate upstream for help. Irc at freenode , chanel mate is a good place.