(In reply to comment #0)
> I am trying to configure dual-head on my laptop via KControl -> System
> Administration -> Monitor & Display. Whenever I go to apply my changes on any
> tab, or click "Test Settings" on the Resolution and Layout tab, the KControl
> module crashes. KControl itself remains open, but resets to the summary page
> for System Administration. It does apply the changed settings, and it saves
> them, but then I have to re-click the Monitor & Display button and re-enter my
> root password for administration mode.
> 
> The crash handler was unable to produce a valid backtrace, with the message:
> 
> =======================================
> This backtrace appears to be of no use.
> This is probably because your packages are built in a way which prevents
> creation of proper backtraces, or the stack frame was seriously corrupted in
> the crash.
> =======================================
> 
> As far as I can tell, I have the needed -dbg packages installed for every
> component of TDE I have installed, so I doubt this is the problem (unless the
> -dbg packages are corrupt somehow).

Seems kcrash is broken or a sort of it. I can't confirm it but I've been unable to get backtrace from it either. 

You can use gdb for it: 
1) run in terminal: gdb kcontrol
2) type in gdb commands:
set follow-fork-mode child
set detach-on-fork off
run
3) make it crash
4) type in gdb: bt

From the command line or mini-cli (Alt F2) run crashtest. That executable is intended to test crash handling and backtraces. :)

(In reply to comment #1)
> (In reply to comment #0)
> > I am trying to configure dual-head on my laptop via KControl -> System
> > Administration -> Monitor & Display. Whenever I go to apply my changes on any
> > tab, or click "Test Settings" on the Resolution and Layout tab, the KControl
> > module crashes. KControl itself remains open, but resets to the summary page
> > for System Administration. It does apply the changed settings, and it saves
> > them, but then I have to re-click the Monitor & Display button and re-enter my
> > root password for administration mode.
> > 
> > The crash handler was unable to produce a valid backtrace, with the message:
> > 
> > =======================================
> > This backtrace appears to be of no use.
> > This is probably because your packages are built in a way which prevents
> > creation of proper backtraces, or the stack frame was seriously corrupted in
> > the crash.
> > =======================================
> > 
> > As far as I can tell, I have the needed -dbg packages installed for every
> > component of TDE I have installed, so I doubt this is the problem (unless the
> > -dbg packages are corrupt somehow).
> 
> Seems kcrash is broken or a sort of it. I can't confirm it but I've been unable
> to get backtrace from it either. 
> 
> You can use gdb for it: 
> 1) run in terminal: gdb kcontrol
> 2) type in gdb commands:
> set follow-fork-mode child
> set detach-on-fork off
> run
> 3) make it crash
> 4) type in gdb: bt

That seems to be interfering with it's ability to call tdesu when I try to enter administrative mode -- the module blanks and is solid grey, and Kcontrol freezes without ever producing a crash. The only way to get rid of it is to kill it via TDE System Guard, or by telling gdb to quit.

(In reply to comment #2)
> From the command line or mini-cli (Alt F2) run crashtest. That executable is
> intended to test crash handling and backtraces. :)

crashtest is non-existent on my system, regardless of whether I'm root or normal user.

> crashtest is non-existent on my system, regardless of whether I'm root or normal user.

Then your version of tdebase was built with -DBUILD_CRASHTEST=OFF. You might want to mention that to whomever created your packages. :0

(In reply to comment #5)
> > crashtest is non-existent on my system, regardless of whether I'm root or normal user.
> 
> Then your version of tdebase was built with -DBUILD_CRASHTEST=OFF. You might
> want to mention that to whomever created your packages. :0

Am I right in assuming it's Tim who maintains the Debian nightlies?

(In reply to comment #6)
> (In reply to comment #5)
> > > crashtest is non-existent on my system, regardless of whether I'm root or normal user.
> > 
> > Then your version of tdebase was built with -DBUILD_CRASHTEST=OFF. You might
> > want to mention that to whomever created your packages. :0
> 
> Am I right in assuming it's Tim who maintains the Debian nightlies?

Yes, your assumption is correct.

In this case, however, all you need to do is:
sudo gdb --arg kcmshell.real displayconfig

That will start the displayconfig module as root under a GDB session and allow you to grab a backtrace.

Regarding the kcrash failure, I don't know if newer Ubuntu kernels even allow you to grab a backtrace of a program running under sudo.

Yes. Here is the build script:

http://git.trinitydesktop.org/cgit/tde-packaging/tree/ubuntu/precise/tdebase/debian/rules

In the tdebase CMakeLists.txt, BUILD_CRASHTEST defaults to $BUILD_ALL and BUILD_ALL defaults to OFF. Therefore to build crashtest requires explicitly declaring BUILD_CRASHTEST=ON.

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > > crashtest is non-existent on my system, regardless of whether I'm root or normal user.
> > > 
> > > Then your version of tdebase was built with -DBUILD_CRASHTEST=OFF. You might
> > > want to mention that to whomever created your packages. :0
> > 
> > Am I right in assuming it's Tim who maintains the Debian nightlies?
> 
> Yes, your assumption is correct.
> 
> In this case, however, all you need to do is:
> sudo gdb --arg kcmshell.real displayconfig
> 
> That will start the displayconfig module as root under a GDB session and allow
> you to grab a backtrace.
> 
> Regarding the kcrash failure, I don't know if newer Ubuntu kernels even allow
> you to grab a backtrace of a program running under sudo.

I don't use Ubuntu, nor am I a fan of sudo, so tying to sudo gdb isn't going to work on my system.

Trying it via tdesu and su -c (both in Konsole) doesn't work -- tdesu just hangs, and going through su -c gives the following error (after the gdb license):

------------------------------------
kcmshell.real: No such file or directory.
(gdb) set follow-fork-mode child
(gdb) set detach-on-fork off
(gdb) run
Starting program:  displayconfig
No executable file specified.
Use the "file" or "exec-file" command.
(gdb) quit
------------------------------------

(In reply to comment #9)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> > > > > crashtest is non-existent on my system, regardless of whether I'm root or normal user.
> > > > 
> > > > Then your version of tdebase was built with -DBUILD_CRASHTEST=OFF. You might
> > > > want to mention that to whomever created your packages. :0
> > > 
> > > Am I right in assuming it's Tim who maintains the Debian nightlies?
> > 
> > Yes, your assumption is correct.
> > 
> > In this case, however, all you need to do is:
> > sudo gdb --arg kcmshell.real displayconfig
> > 
> > That will start the displayconfig module as root under a GDB session and allow
> > you to grab a backtrace.
> > 
> > Regarding the kcrash failure, I don't know if newer Ubuntu kernels even allow
> > you to grab a backtrace of a program running under sudo.
> 
> I don't use Ubuntu, nor am I a fan of sudo, so tying to sudo gdb isn't going to
> work on my system.
> 
> Trying it via tdesu and su -c (both in Konsole) doesn't work -- tdesu just
> hangs, and going through su -c gives the following error (after the gdb
> license):
> 
> ------------------------------------
> kcmshell.real: No such file or directory.
> (gdb) set follow-fork-mode child
> (gdb) set detach-on-fork off
> (gdb) run
> Starting program:  displayconfig
> No executable file specified.
> Use the "file" or "exec-file" command.
> (gdb) quit
> ------------------------------------
If you are not using Ubuntu try kcmshell instead of kcmshell.real.

Tim

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > (In reply to comment #5)
> > > > > > crashtest is non-existent on my system, regardless of whether I'm root or normal user.
> > > > > 
> > > > > Then your version of tdebase was built with -DBUILD_CRASHTEST=OFF. You might
> > > > > want to mention that to whomever created your packages. :0
> > > > 
> > > > Am I right in assuming it's Tim who maintains the Debian nightlies?
> > > 
> > > Yes, your assumption is correct.
> > > 
> > > In this case, however, all you need to do is:
> > > sudo gdb --arg kcmshell.real displayconfig
> > > 
> > > That will start the displayconfig module as root under a GDB session and allow
> > > you to grab a backtrace.
> > > 
> > > Regarding the kcrash failure, I don't know if newer Ubuntu kernels even allow
> > > you to grab a backtrace of a program running under sudo.
> > 
> > I don't use Ubuntu, nor am I a fan of sudo, so tying to sudo gdb isn't going to
> > work on my system.
> > 
> > Trying it via tdesu and su -c (both in Konsole) doesn't work -- tdesu just
> > hangs, and going through su -c gives the following error (after the gdb
> > license):
> > 
> > ------------------------------------
> > kcmshell.real: No such file or directory.
> > (gdb) set follow-fork-mode child
> > (gdb) set detach-on-fork off
> > (gdb) run
> > Starting program:  displayconfig
> > No executable file specified.
> > Use the "file" or "exec-file" command.
> > (gdb) quit
> > ------------------------------------
> If you are not using Ubuntu try kcmshell instead of kcmshell.real.
> 
> Tim

It still will not work, even though I know for fact that kcmshell exists in /opt/trinity/bin .

It appears that "su -c" will not pick up on kcmshell, even though I know I have /opt/trinity/bin in both my and root's PATH, as per the ~/.profile file.

Running directly as root seems to make it unable to connect the display being used by Xorg.

(In reply to comment #11)
> It still will not work, even though I know for fact that kcmshell exists in
> /opt/trinity/bin .
> 
> It appears that "su -c" will not pick up on kcmshell, even though I know I have
> /opt/trinity/bin in both my and root's PATH, as per the ~/.profile file.
> 
> Running directly as root seems to make it unable to connect the display being
> used by Xorg.
just enable local connections to xorg:
1. xhost +local:
2. su
3. export DISPLAY=':0' # or whatever
3. run gdb etc

(In reply to comment #12)
> (In reply to comment #11)
> > It still will not work, even though I know for fact that kcmshell exists in
> > /opt/trinity/bin .
> > 
> > It appears that "su -c" will not pick up on kcmshell, even though I know I have
> > /opt/trinity/bin in both my and root's PATH, as per the ~/.profile file.
> > 
> > Running directly as root seems to make it unable to connect the display being
> > used by Xorg.
> just enable local connections to xorg:
> 1. xhost +local:
> 2. su
> 3. export DISPLAY=':0' # or whatever
> 3. run gdb etc

I wasn't aware I could do that. Thanks :-)

The Kcontrol module refused to appear until AFTER I quit gdb. However, it does seem to have enabled the TDE Crash Handler to produce the needed debugger output, which I will be attaching.

Created attachment 1014 [details]
Debugger output pertaining to this bug

(In reply to comment #14)
> Created attachment 1014 [details]
> Debugger output pertaining to this bug

Fix pushed to GIT in hash 1d811a9.  Nightly builds with this patch included should be available in the next few days; please test at that point and report back.

Kris,

can you confirm, if problem is solved?

Thanks

(In reply to comment #16)
> Kris,
> 
> can you confirm, if problem is solved?
> 
> Thanks

Currently, I am unable to test.

Once I have the essentials setup on my new laptop, I will be able to resume testing and see if this bug is fixed.

I finally got around to testing on my old laptop running Debian Squeeze. It has been fully dist-upgrade'ed and running the latest nightlies as of today.

It seems to be fixed. I managed to successfully enable dual-head without the module crashing, though I had to do it twice -- the dialog to confirm, and KControl, both appeared on the second monitor when I clicked Apply, and it's an old CRT that takes a few seconds to light up by which time the timeout on the confirmation is about to run out.

*** Bug 1353 has been marked as a duplicate of this bug. ***