This might be permissions related. I can start kpowersave as root.

Note: this is the kpowersave-nohal edition.

I can't reproduce this.  It looks like something is going wrong in DBUS but is not very specific about what actually happened.

As DBUS can be unstable depending on a host of external factors, I will need confirmation of this bug on another system before debugging further.  At the very least DBUS should be rebuilt with -rdynamic as suggested in the error message, and all DBUS/libdbus debugging symbols installed.

I'm trying to rebuild a dbus package using -rdynamic but am not succeeding.

Although the stdout references that dbus is not build with backtrace support, the message above that seems to provide a clue of the cause:

TQSocketNotifier: Multiple socket notifiers for same socket 12 and type read
process 14637: arguments to dbus_message_new_method_call() were incorrect,
assertion "interface == NULL || _dbus_check_is_valid_interface (interface)"
failed in file dbus-message.c line 1206.

I made the following change to the dbus build script:

CFLAGS="$SLKCFLAGS -rdynamic"

Per the configure script, I also tried this:

CFLAGS="$SLKCFLAGS -export-dynamic"

I am not noticing any difference in the backtrace and I still see the same message that dbus is unable to print a backtrace.

I really, really hate DBUS sometimes (well, most of the time actually! :-))  DCOP is so simple and reliable by comparison...

There are only a few places in the TDE hardware library that make DBUS calls, and most are related to upower and similar services.  Is there any way to at least get an unstripped version of kpowersave installed on your system so that the kpowersave portion of the backtrace becomes valid?

Other things to try might be to launch kpowersave with gdb via 'gdb kpowersave'; sometimes this allows more of the backtrace to be gathered vs. attaching after the crash has already occurred.  Compiling kpowersave-nohal with no optimization (CXXFLAGS '-O0' IIRC) would also help.

Sorry I can't help much more, all the backtrace tells me is that DBUS broke yet again! :-(

If by unstripped you mean not stripping the debug symbols, I build all of my Trinity packages that way already.

Using gdb results in the same crashhandler backtrace and same stderr in konsole.

I didn't try compiling with no optimization.

The oddity to me is I can start kpowersave when running Trinity as root. When I start kpowersave in konsole as root, I see the following:

[tdehardwaredevices] Rules file /opt/trinity/share/apps/tdehwlib/deviceclasses/floppydisk-platform.hwclass used to set device subtype for device at path /sys/devices/platform/floppy.0/block/fd0/
[FIXME] HardwareInfo::setPowerSave unimplemented!

As root I can access the configuration dialogs, no crashes.

The differences in the two konsole outputs might be a clue in the sense that the code is branching at different places because of different results.

Normally I'd say this is a permissions problem, and that might well be, but I don't know what files to check. Everything seems in order in the dbus-tqt3 and kpowersave packages.

I'm not concerned about this bug for myself. I never use kpowersave --- I build packages and nominally test them in the spirit of the project. Either nobody is testing the second tier apps or nobody else is seeing the problem. I tagged this report as critical only because I presumed others would have the same problem. Feel free to bump this to Normal if nobody else is seeing anything awry.

Just curious: the error message about the sockets. Is tdehwlib/kpowersave/dbus trying to create socket files where the permissions are wrong? Where does tdehwlib/kpowersave/dbus try to create socket files?

I am concerned about this report for the same reasons you mention--even though I have never seen it crash (and I use it on almost every TDE installation I have!), I don't like knowing that under some unknown conditions it will fail.

Can you post detailed system specifications (computer, processor type, etc. along with distro name, architecture, version, etc.)?  If this could be reproduced in a virtual machine I might be able to do something about it...

Thanks!

Let me try starting kpowersave in different environments, including a VM. I have to get them all updated with the same package set. If the result is the same then we can lean toward a generic Slackware issue or PEBKAC. I'm still suspicious about permissions.

I tried using strace but the output file does not capture the crash failure. Perhaps I need a certain strace option.

Some good news. I am able to start kpowersave in a VM using a non-root account.

The VM is hosted on my primary system, which means the hardware layer is mostly the same. An obvious difference includes the video drivers, but there are other differences too.

My HTPC is a dual core and uses the same nvidia drivers. I can't start kpowersave there with a non-root account. Conversely, I keep the HTPC configured almost the same as my primary system with only minor differences, so the common video drivers might not mean much.

That same non-root account that is able to start kpowersave in the VM can't start kpowersave on either my primary system or HTPC.

I have a PI and PII system here that I will test. Those systems have obvious different hardware and video drivers. They are old and horribly slow and will take me a few hours to update them with the same latest Trinity package set.

I don't know whether than small bit of news will help focus where to troubleshoot.

Can you try temporarily removing upower completely from one of the systems that is crashing?  If the crash continues to occur then this test will have eliminated a large amount of code as the potential culprit...

Thanks!

Removing the upower package and rebooting resulted in the same crash.

(In reply to comment #13)
> Removing the upower package and rebooting resulted in the same crash.

Intriguing!

There is one more thing you can try.  tdelibs installs a small DBUS daemon tde_dbus_hardwarecontrol; try moving that file to a backup location and rebooting.  Then try running kpowersave as both root and a standard user; is there any change in the crash and/or does kpowersave start crashing as root?

Thanks!

I renamed tde_dbus_hardwarecontrol and saw the same results. Non-root crashes, root starts kpowersave. I did not reboot the system. I exited and restarted Trinity (I start X from the command line with startx).

(In reply to comment #15)
> I renamed tde_dbus_hardwarecontrol and saw the same results. Non-root crashes,
> root starts kpowersave. I did not reboot the system. I exited and restarted
> Trinity (I start X from the command line with startx).

That may not be sufficient as DBUS itself launches tde_dbus_hardwarecontrol, meaning that the process will usually remain loaded until the machine is rebooted.

Same results with a full reboot. No crash with root, crash with non-root.

(In reply to comment #17)
> Same results with a full reboot. No crash with root, crash with non-root.

Well, this has me stumped.  With upower and the tde_dbus_hardwarecontrol service gone, the TDE hardware library should not be using any DBUS services related to kpowersave.  I really wish there was a way to spy on DBUS to see what exactly was being called when...

I know this bothers you, but let's change this to report to Normal and Slackware 14. I'm the only one seeing this and I don't use the app other than project testing.

OK, status updated.  Sorry I can't be of any more help!

More notes.

No problems with non-root starting kpowersave on my PI and PII machines.

All tested systems, including the VM, are using 32-bit OSs. All use the same kernel and an initrd, although only the dual core systems use an SMP kernel.

Obvious differences that I am aware: kernel, dual core vs. single, video drivers, services that are started, raw speed.

Might be cpufreq related; tdepowersave does monitor the CPU frequencies with a socket notifier IIRC.  However, this does not explain the DBUS failure.

I am planning to test that. :) I use CPU frequency scaling only on the two affected systems.

Bingo! I disabled CPU frequency scaling and then non-root users could start kpowersave. I verified this on both dual core systems.

I don't know about the dbus relationship, but I remain suspicious of file permissions. I know that Debian and Slackware packages do not always install files in the same exact location or assign directory permissions the same. For example, perhaps Slackware installs a file to /usr/sbin while the same package in Debian might install the same file to /usr/bin. The same might be true for socket file locations or directory permissions.

I'm leaning toward the crash being permissions related because on the two dual core systems with CPU frequency scaling enabled, root does not experience a crash when starting kpowersave. Almost always that indicates a permissions problem.

With that said, what does tdehwlib look for with respect to CPU frequency that could be permissions related?

Superfluous side note:

I was browsing tdehardwaredevices.cpp looking for ideas. I noticed the comment at line 1170:

// can set brightness?

Probably should be:

// can set CPU governor?

:)

(In reply to comment #24)
> Bingo! I disabled CPU frequency scaling and then non-root users could start
> kpowersave. I verified this on both dual core systems.
> 
> I don't know about the dbus relationship, but I remain suspicious of file
> permissions. I know that Debian and Slackware packages do not always install
> files in the same exact location or assign directory permissions the same. For
> example, perhaps Slackware installs a file to /usr/sbin while the same package
> in Debian might install the same file to /usr/bin. The same might be true for
> socket file locations or directory permissions.
> 
> I'm leaning toward the crash being permissions related because on the two dual
> core systems with CPU frequency scaling enabled, root does not experience a
> crash when starting kpowersave. Almost always that indicates a permissions
> problem.
> 
> With that said, what does tdehwlib look for with respect to CPU frequency that
> could be permissions related?

Quite a bit, actually!  Most of the code is in tdelibs, in the TDECPUDevice class.  The TDE HW library falls back to upower access over DBUS if it cannot directly access the cpufreq files in /proc, which probably explains the crash only occurring when kpowersave was started from a non-root account.

That being said, kpowersave should not be crashing even if the DBUS service is not accessible.  Let me run a few tests here to see if I can reproduce the crash by denying access to the org.trinitydesktop.hardwarecontrol DBUS service.

(In reply to comment #25)
> Superfluous side note:
> 
> I was browsing tdehardwaredevices.cpp looking for ideas. I noticed the comment
> at line 1170:
> 
> // can set brightness?
> 
> Probably should be:
> 
> // can set CPU governor?
> 
> :)

Yes, it should.  I just noticed that myself. :-)

(In reply to comment #26)
> Quite a bit, actually!  Most of the code is in tdelibs, in the TDECPUDevice
> class.  The TDE HW library falls back to upower access over DBUS if it cannot
> directly access the cpufreq files in /proc, which probably explains the crash
> only occurring when kpowersave was started from a non-root account.
> 
> That being said, kpowersave should not be crashing even if the DBUS service is
> not accessible.  Let me run a few tests here to see if I can reproduce the
> crash by denying access to the org.trinitydesktop.hardwarecontrol DBUS service.

Correction: that should read "org.trinitydesktop.hardwarecontrol", not "upower", above.

If I understand the basic flow of events in tdehardwaredevices.cpp, tdehwlib asks dbus whether certain permissions exist.

On Slackware, only root can adjust the CPU frequency governor. That could explain 1) why root can start kpowersave and non-root can't and 2) why when CPU frequency scaling is disabled there is no crash. In the first instance the reply is yes and in the second instance there is no dbus query because cpufreq/scaling_governor does not exist.

Just blabbering out loud. :-)

I got dbus rebuilt with a tad more verbosity. With CPU frequency scaling enabled, running kpowersave from konsole results in the following output:

[tdehardwaredevices] Rules file /opt/trinity/share/apps/tdehwlib/deviceclasses/floppydisk-platform.hwclass used to set device subtype for device at path /sys/devices/platform/floppy.0/block/fd0/
TQSocketNotifier: Multiple socket notifiers for same socket 12 and type read
process 6259: arguments to dbus_message_new_method_call() were incorrect, assertion "interface == NULL || _dbus_check_is_valid_interface (interface)" failed in file dbus-message.c line 1206.
This is normally a bug in some application using the D-Bus library.
  /usr/lib/libdbus-1.so.3(+0x4b949) [0xb75ec949]
  /usr/lib/libdbus-1.so.3(+0x4ede4) [0xb75efde4]
  /usr/lib/libdbus-1.so.3(+0x3ad61) [0xb75dbd61]
  /usr/lib/libdbus-1.so.3(dbus_message_new_method_call+0x1e4) [0xb75c3fb4]
  /opt/trinity/lib/libdbus-1-tqt.so.0(_ZNK15TQT_DBusMessage13toDBusMessageEv+0x10b) [0xb602451b]
  /opt/trinity/lib/libdbus-1-tqt.so.0(_ZNK18TQT_DBusConnection13sendWithReplyERK15TQT_DBusMessageP13TQT_DBusError+0x47) [0xb6010da7]
  /opt/trinity/lib/libdbus-1-tqt.so.0(_ZNK13TQT_DBusProxy13sendWithReplyERK8TQStringRK11TQValueListI12TQT_DBusDataEP13TQT_DBusError+0xcd) [0xb6026b7d]
  /opt/trinity/lib/libtdecore.so.4(_ZN12TDECPUDevice14canSetGovernorEv+0x254) [0xb6b75b54]
  /opt/trinity/lib/libtdeinit_kpowersave.so(_ZN12HardwareInfo12checkCPUFreqEv+0x1da) [0xb7697e4a]
  /opt/trinity/lib/libtdeinit_kpowersave.so(_ZN12HardwareInfoC2Ev+0x43f) [0xb76a0a8f]
  /opt/trinity/lib/libtdeinit_kpowersave.so(_ZN10kpowersaveC1Ebb+0x327) [0xb76eb997]
  /opt/trinity/lib/libtdeinit_kpowersave.so(kdemain+0x2b5) [0xb76f1805]
  kpowersave(main+0x1b) [0x804873b]
  /lib/libc.so.6(__libc_start_main+0xf5) [0xb5d405a5]
  kpowersave() [0x8048761]
[kcrash] TDECrash: crashing... crashRecursionCounter = 2
[kcrash] TDECrash: Application Name = kpowersave path = <unknown> pid = 6259


crashhandler backtrace:


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[TDECrash handler]
#5  0xb5d56af5 in raise () from /lib/libc.so.6
#6  0xb5d58453 in abort () from /lib/libc.so.6
#7  0xb75efe05 in _dbus_abort () from /usr/lib/libdbus-1.so.3
#8  0xb75dbd61 in _dbus_warn_check_failed () from /usr/lib/libdbus-1.so.3
#9  0xb75c3fb4 in dbus_message_new_method_call () from /usr/lib/libdbus-1.so.3
#10 0xb602451b in TQT_DBusMessage::toDBusMessage (this=0xbfb10f90) at /dev/shm/dbus-1-tqt/tqdbusmessage.cpp:141
#11 0xb6010da7 in TQT_DBusConnection::sendWithReply (this=0x9098488, message=..., error=0x909849c) at /dev/shm/dbus-1-tqt/tqdbusconnection.cpp:280
#12 0xb6026b7d in TQT_DBusProxy::sendWithReply (this=0xbfb11024, method=..., params=..., error=0x0) at /dev/shm/dbus-1-tqt/tqdbusproxy.cpp:159
#13 0xbfb11068 in ?? ()
#14 0x000001c7 in ?? ()
#15 0xb773cad0 in ?? () from /opt/trinity/lib/libtdeinit_kpowersave.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

FYI, I see the dbus assertions on my test system (now that I am looking for them!), but dbus does not crash.  This looks like two bugs, one in TDE and one in libdbus--if I fix the TDE bug, the libdbus bug (crash) will likely not be triggered.

This should be resolved in GIT hash ea0df49 (tdelibs).  The problem boiled down to a comma instead of a period in a DBUS interface specifier.

This simple problem is a perfect example of why I hate the implementation of DBUS.  Not only does one call take 22 lines of C++ code (!!), but this extreme verbosity makes it very hard to spot simple errors such as this one.  If the error slips by the programmer's spot check, DBUS then tends to crash or fail in very mysterious ways, with some of the most unhelpful error messages I have ever seen (they are even worse than even Microsoft's generic error codes!!).  By contrast, a DCOP call takes a few lines of C++ at most and provides helpful, plain-text error messages.

Rebuilt. No more crashing. Great work and thanks!