I was having a bug (segfault; I re-emerged all ebuilds listed by something like emerge -ep world |grep krellm emerge -va1 app-admin/gkrellm x11-themes/gkrellm-themes x11-plugins/gkrellm-reminder x11-plugins/gkrellm-radio x11-plugins/gkrellm-xkb x11-plugins/gkrellmwireless x11-plugins/gkrellmlaunch x11-plugins/gkrelltop x11-plugins/gkrellm-gamma x11-plugins/gkrellm-countdown x11-plugins/gkrellm-hddtemp x11-plugins/gkrellm-leds x11-plugins/gkrellm-volume x11-plugins/gkrellmss x11-plugins/gkrellmms and bug persists: dhp@moon_gen_2:~/.gkrellm2/themes/dirtchamber$ gkrellm (gkrellm:21060): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() (gkrellm:21060): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() (gkrellm:21060): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() (gkrellm:21060): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() (gkrellm:21060): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() Segmentation fault I have been using this skin for years (at least 2 or 3). More logs coming.
Created attachment 133491 [details] /tmp/emerge--info My flags: root@moon_gen_2:~# emerge -va1 app-admin/gkrellm x11-themes/gkrellm-themes x11-plugins/gkrellm-reminder x11-plugins/gkrellm-radio x11-plugins/gkrellm-xkb x11-plugins/gkrellmwireless x11-plugins/gkrellmlaunch x11-plugins/gkrelltop x11-plugins/gkrellm-gamma x11-plugins/gkrellm-countdown x11-plugins/gkrellm-hddtemp x11-plugins/gkrellm-leds x11-plugins/gkrellm-volume x11-plugins/gkrellmss x11-plugins/gkrellmms These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-admin/gkrellm-2.3.0 USE="X gnutls hddtemp lm_sensors nls ssl" 0 kB [ebuild R ] x11-themes/gkrellm-themes-0.1 0 kB [ebuild R ] x11-plugins/gkrellm-reminder-2.0.0 0 kB [ebuild R ] x11-plugins/gkrellm-radio-2.0.4 USE="lirc" 0 kB [ebuild R ] x11-plugins/gkrellm-xkb-1.05 0 kB [ebuild R ] x11-plugins/gkrellmwireless-2.0.3 0 kB [ebuild R ] x11-plugins/gkrellmlaunch-0.5 0 kB [ebuild R ] x11-plugins/gkrelltop-2.2.6-r1 0 kB [ebuild R ] x11-plugins/gkrellm-gamma-2.03-r1 0 kB [ebuild R ] x11-plugins/gkrellm-countdown-0.1.2 0 kB [ebuild R ] x11-plugins/gkrellm-hddtemp-0.2_beta-r1 0 kB [ebuild R ] x11-plugins/gkrellm-leds-0.8.1 0 kB [ebuild R ] x11-plugins/gkrellm-volume-2.1.13 USE="alsa" 0 kB [ebuild R ] x11-plugins/gkrellmss-2.6 USE="alsa esd nls" 0 kB [ebuild R ] x11-plugins/gkrellmms-2.1.22-r1 0 kB Total: 15 packages (15 reinstalls), Size of downloads: 0 kB
Created attachment 133492 [details] /tmp/gkrellm_strace_log Hope this is helpfull. hmmm, maybe it's again that /dev/radio bug I met on debian 4 years ago ... or gettimeofday() call ? I am having "time problems" with mplayer since my last update 12h ago: movies are played about 8% too fast; maybe something wrong in the RTC driver ? Linux API ? ...
emerge -C x11-plugins/gkrellm-radio fixed it. Changing topic from > app-admin/gkrellm-2.3.0 Segmentation fault to > app-admin/gkrellm-2.3.0 Segmentation fault when x11-plugins/gkrellm-radio-2.0.4 installed Thus removing bug 195522 block. I tried to reproduce again: remerge => rebug remove => solved and so on ...
Indeed, there is a bug - If /dev/radio doesn't exist, this plugin blows up. I may devise a simple "Don't segfault, just die slightly more sane" patch.
In the mean time I have removed it from the meta "gkrellm-plugins" package, just in case. Hopefully you would only install this if you have a radio tuner card anyway, and would therefore have this device node present...
Still happens with app-admin/gkrellm-2.3.1
(In reply to comment #6) > Still happens with app-admin/gkrellm-2.3.1 Yes, it's definitely due to a bug in the x11-plugins/gkrellm-radio plugin which has very little to do with gkrellm itself. I'm sure every version of gkrellm will segfault in the same way if you try to initialize the gkrellm-radio plugin without a /dev/radio device present. I just haven't had a chance to patch the plugin itself. If you do, please post the patch here and I'll incorporate it into the gkrellm-radio plugin.
Odd: I can't seem to reproduce with gkrellm-2.3.4. Would you mind retesting with latest?
I will try, IIRC, the bug may depend on how devfs/udev creates the nodes ... Some particular udev conf will create what the original author had on his box; but udev variations maye create node with "wrong" names; IIRC, /dev/radio vs /dev/radio0 ... so, a simple mv from one to an other may help repro. May need weeks before I have time to bother about this in details.
I am unable to reproduce this bug with gkrellm-2.3.4 on a system that has no /dev/radio present at all, this was probably fixed by some of the stability enhancements between gkrellm-2.3.0 and -2.3.4.