This crash appears to be occurring in widget drawing code.

What widget style are you using?

(In reply to Timothy Pearson from comment #1)
> This crash appears to be occurring in widget drawing code.
> 
> What widget style are you using?

Recently I've been using QtCurve, however I saw it happen earlier with Plastik. I haven't tried it with other styles.

Just verifying, you are seeing this crash with the latest nightlies but it was not present in RC1?

I ask as this is not going to be easy to fix; there is a threading issue of some type and this will probably have to be triaged for an R14 SRU.

(In reply to Timothy Pearson from comment #3)
> Just verifying, you are seeing this crash with the latest nightlies but it
> was not present in RC1?
<snip>

Yes (to the nightlies part) and I don't know (to the RC1 part - I've never installed RC1, I've been with the nightlies for several months).

(In reply to Kristopher from comment #0)
> Created attachment 2372 [details]
> gdb backtrace from a Control Center crash from today
> 
> Since updating the nightlies 30 November 2014, Control Center seems to crash
> frequently. I have attached a backtrace from gdb.

Unfortunately the backtrace is not useful; the function calls between TQWidget::isActiveWindow and TQObject::insertChild have been optimized out so I don't even know where to begin looking for the problem.

Can you provide steps to make kcontrol crash?  If I can reproduce the issue here then I can fix it much easier.

If I can't reproduce the issue then you would need to rebuild and reinstall TQt3 with the '-O0 -g' flags passed to GCC; right now -O2 is used on the production builds which is making debugging from the provided backtrace impossible.

Thanks!

(In reply to Timothy Pearson from comment #5)
> (In reply to Kristopher from comment #0)
> > Created attachment 2372 [details]
> > gdb backtrace from a Control Center crash from today
> > 
> > Since updating the nightlies 30 November 2014, Control Center seems to crash
> > frequently. I have attached a backtrace from gdb.
> 
> Unfortunately the backtrace is not useful; the function calls between
> TQWidget::isActiveWindow and TQObject::insertChild have been optimized out
> so I don't even know where to begin looking for the problem.
> 
> Can you provide steps to make kcontrol crash?  If I can reproduce the issue
> here then I can fix it much easier.
> 
> If I can't reproduce the issue then you would need to rebuild and reinstall
> TQt3 with the '-O0 -g' flags passed to GCC; right now -O2 is used on the
> production builds which is making debugging from the provided backtrace
> impossible.
> 
> Thanks!

1. Open Control Center
2. Change a setting
3. Click Apply
4. Close Control Center via either keyboard shortcut (for me, that's ALT+F4) or by clicking the X in the titlebar

The crashes are random, so you may need to try a few times, but on the latest nightlies it's frequent enough that it shouldn't take too long.

Mostly I've been tweaking stuff under Appearance & Themes, though I cannot confirm whether or not that has anything to do with it. I can at least confirm that it doesn't seem to matter which of the Appearance & Themes modules you need to use to reproduce.

Unfortunately I still can't reproduce this.

If you could recompile/reinstall tqt3 with "-O0 -g" and regenerate the backtrace I might have a chance of fixing this bug.  Simplest way is probably to download the tqt-x11-free Debian package, run dpkg-buildpackage on it and then:
cd src/
edit Makefile and replace all instances of "-O2" with "-O0 -g"
make clean
make install

(In reply to Timothy Pearson from comment #7)
> Unfortunately I still can't reproduce this.
> 
> If you could recompile/reinstall tqt3 with "-O0 -g" and regenerate the
> backtrace I might have a chance of fixing this bug.  Simplest way is
> probably to download the tqt-x11-free Debian package, run dpkg-buildpackage
> on it and then:
> cd src/
> edit Makefile and replace all instances of "-O2" with "-O0 -g"
> make clean
> make install

My experience with dpkg is limited to running "dpkg -i" on a .deb file, and my one and only "attempt" at learning how things work on the packager side nearly put me in a straight jacket.

If I am to rebuild the package as you suggest using dpkg, I'll need more specific instructions, including where to download the source package. If that would prove too long (or impractical) for posting a comment here, I can come on IRC or talk via XMPP later on today. Or, if nightlies are hidden somewhere for an RPM-based distro (I'm quite comfortable (re)building packages in RPM), I can try there.

(In reply to Kristopher from comment #8)
> (In reply to Timothy Pearson from comment #7)
> > Unfortunately I still can't reproduce this.
> > 
> > If you could recompile/reinstall tqt3 with "-O0 -g" and regenerate the
> > backtrace I might have a chance of fixing this bug.  Simplest way is
> > probably to download the tqt-x11-free Debian package, run dpkg-buildpackage
> > on it and then:
> > cd src/
> > edit Makefile and replace all instances of "-O2" with "-O0 -g"
> > make clean
> > make install
> 
> My experience with dpkg is limited to running "dpkg -i" on a .deb file, and
> my one and only "attempt" at learning how things work on the packager side
> nearly put me in a straight jacket.
> 
> If I am to rebuild the package as you suggest using dpkg, I'll need more
> specific instructions, including where to download the source package. If
> that would prove too long (or impractical) for posting a comment here, I can
> come on IRC or talk via XMPP later on today. Or, if nightlies are hidden
> somewhere for an RPM-based distro (I'm quite comfortable (re)building
> packages in RPM), I can try there.

Well if you're game to try I can provide detailed instructions...
Don't try this with a running TDE instance; when you execute "make install" at the end it will unsafely and immediately terminate your session as it replaces the tqt3-mt library.

As root:
apt-get install devscripts fakeroot
apt-get build-dep tqt-x11-free
mkdir TEMP
cd TEMP
apt-get source tqt-x11-free
cd tqt-x11-free-*
dpkg-buildpackage -rfakeroot -b
cd src
nano <or vi, etc.> Makefile
<change all "-O2" instances to "-O0 -g">
make clean
make install

Then try to reproduce the bug.

If you need help let me know; Email is best but I can also hop on IRC if needed.

Thanks!

Tim

(In reply to Timothy Pearson from comment #9)
> (In reply to Kristopher from comment #8)
> > (In reply to Timothy Pearson from comment #7)
> > > Unfortunately I still can't reproduce this.
> > > 
> > > If you could recompile/reinstall tqt3 with "-O0 -g" and regenerate the
> > > backtrace I might have a chance of fixing this bug.  Simplest way is
> > > probably to download the tqt-x11-free Debian package, run dpkg-buildpackage
> > > on it and then:
> > > cd src/
> > > edit Makefile and replace all instances of "-O2" with "-O0 -g"
> > > make clean
> > > make install
> > 
> > My experience with dpkg is limited to running "dpkg -i" on a .deb file, and
> > my one and only "attempt" at learning how things work on the packager side
> > nearly put me in a straight jacket.
> > 
> > If I am to rebuild the package as you suggest using dpkg, I'll need more
> > specific instructions, including where to download the source package. If
> > that would prove too long (or impractical) for posting a comment here, I can
> > come on IRC or talk via XMPP later on today. Or, if nightlies are hidden
> > somewhere for an RPM-based distro (I'm quite comfortable (re)building
> > packages in RPM), I can try there.
> 
> Well if you're game to try I can provide detailed instructions...
> Don't try this with a running TDE instance; when you execute "make install"
> at the end it will unsafely and immediately terminate your session as it
> replaces the tqt3-mt library.
> 
> As root:
> apt-get install devscripts fakeroot
> apt-get build-dep tqt-x11-free
> mkdir TEMP
> cd TEMP
> apt-get source tqt-x11-free
> cd tqt-x11-free-*
> dpkg-buildpackage -rfakeroot -b
> cd src
> nano <or vi, etc.> Makefile
> <change all "-O2" instances to "-O0 -g">
> make clean
> make install
> 
> Then try to reproduce the bug.
> 
> If you need help let me know; Email is best but I can also hop on IRC if
> needed.
> 
> Thanks!
> 
> Tim

This may seem like a dumb question, but this comes from someone with almost no knowledge pertaining to Debian packaging: will this register the un-optimized version in the package database, or otherwise cause problems when (re/un)installing the package in question? In otherwords, can I safely do this with my main TDE install (which consists entirely of R14 packages)?

I ask because I don't have a spare computer, and I don't quite feel like setting up a VM to do this if I don't have to.

You are perfectly correct to ask.

This will install the un-optimized files over the official optimized files; it will not touch the package database.  To restore your system to the "stock" files you would need to reinstall all tqt3 packages--this is easily done from within synaptic or from the command line with aptitude; if you need commands to run to do this I can provide them.

Created attachment 2378 [details]
Backtrace with un-optimized TQT

I found myself having to compile the tqt package in a VM because apt-get refused to grab the source package on the host machine (dependency issue with gnutls-dev from Debian Backports).

In the VM, with a completely clean TDE configuration, I had trouble making Control Center crash. However, after copying my ~/.trinity/ directory from my host into the VM, I had no issue at all crashing Control Center and obtaining the backtrace. This makes me wander if some update caused some sort of corruption in a configuration file.

(In reply to Kristopher from comment #12)
> Created attachment 2378 [details]
> Backtrace with un-optimized TQT
> 
> I found myself having to compile the tqt package in a VM because apt-get
> refused to grab the source package on the host machine (dependency issue
> with gnutls-dev from Debian Backports).
> 
> In the VM, with a completely clean TDE configuration, I had trouble making
> Control Center crash. However, after copying my ~/.trinity/ directory from
> my host into the VM, I had no issue at all crashing Control Center and
> obtaining the backtrace. This makes me wander if some update caused some
> sort of corruption in a configuration file.

This crash is much different than the one obtained earlier; it indicates a problem with the VirtualBox OpenGL drivers and is probably triggered reliably by selecting the Screen Saver control module.

Can you get the Control Center to crash without accessing the Screen Saver dialog?

Thanks!

(In reply to Timothy Pearson from comment #13)
> This crash is much different than the one obtained earlier; it indicates a
> problem with the VirtualBox OpenGL drivers and is probably triggered
> reliably by selecting the Screen Saver control module.
> 
> Can you get the Control Center to crash without accessing the Screen Saver
> dialog?
> 
> Thanks!

I could not get the crash to occur by visiting the screensaver settings (or anything else in Control Center) *prior* to copying my TDE settings from the host. In addition, the crash from which the backtrace came from was a visit to Appearance & Themes -> Colors , *not* Appearance & Themes -> Screen Saver. Also, 3.5.13.2 is able to load Appearance & Themes -> Screen Saver *without* crashing Control Center.

(In reply to Kristopher from comment #14)
<snip>
> Saver. Also, 3.5.13.2 is able to load Appearance & Themes -> Screen Saver
> *without* crashing Control Center.

That's 3.5.13.2 in VirtualBox with the VirtualBox guest drivers installed, same as now.

(In reply to Kristopher from comment #15)
> (In reply to Kristopher from comment #14)
> <snip>
> > Saver. Also, 3.5.13.2 is able to load Appearance & Themes -> Screen Saver
> > *without* crashing Control Center.
> 
> That's 3.5.13.2 in VirtualBox with the VirtualBox guest drivers installed,
> same as now.

OK, well this is strange then because the backtrace in Attachment 2378 [details] distinctly references OpenGL and the screen saver module.  Can you cause it to crash again and submit a new backtrace?

Thanks!

Created attachment 2384 [details]
Another backtrace

*Hopefully* this one does it...

(In reply to Kristopher from comment #17)
> Created attachment 2384 [details]
> Another backtrace
> 
> *Hopefully* this one does it...

Yep, perfect, thanks!  That should be all the info we need to start working on this.