Bug 2167

Today it crashed despite the fact that I wasn't logging out or using TDM - I was logged in, I walked away from my laptop, and came back to find the TDE Crash Handler alerting me that the TDE Session Manager had crashed. It was unable to produce a backtract. I got booted from TDE and had to log back in. I grabbed the .xsession errors, which mentions a kcrash line saying that ksmserver is crashing. I will attach the end of the file, hopefully it will help.

Created attachment 2337 [details]
End of .xsession-errors mentioning crash

Interesting.  Is this with Slavek's PPA or the nightly builds?

Thanks!

(In reply to Timothy Pearson from comment #3)
> Interesting.  Is this with Slavek's PPA or the nightly builds?
> 
> Thanks!

I don't know what a "Slavek PPA" is - that looks like a reference to some Ubuntu thing, and I am using Debian.

I am using the Nightly Builds mentioned at https://wiki.trinitydesktop.org/Nightly_Builds . I replaced the "ubuntu" reference with "debian" and the "oneirc" reference with "wheezy" to match the fact that I am using Debian Wheezy.

Ah, sorry--one of the other developers (Slavek Banko) put up a more stable PPA for R14 as the nightly builds have been broken more often than not for the past few months.

I haven't seen these crashes on my test boxes, however if you want to help you can probably generate a backtrace this way:
1.) Log in to TDE
2.) Log in to a text-mode console, then attach GDB to the running ksmserver process with "gdb --pid `pidof ksmserver`"
3.) Type "c" to continue execution and press <return>, then switch back to the graphical TDE session and trigger the crash by logging out or whatever is needed.
4.) If ksmserver crashes the session will probably appear to hang instead of popping up a crash handler dialog.  If this happens switch back to the text console you were running gdb on and enter "bt" <return>.  Post the output to this report (if you can do the text mode portion over ssh you can copy + paste the output, otherwise attach a picture to this report).

(In reply to Timothy Pearson from comment #5)
> Ah, sorry--one of the other developers (Slavek Banko) put up a more stable
> PPA for R14 as the nightly builds have been broken more often than not for
> the past few months.
> 
> I haven't seen these crashes on my test boxes, however if you want to help
> you can probably generate a backtrace this way:
> 1.) Log in to TDE
> 2.) Log in to a text-mode console, then attach GDB to the running ksmserver
> process with "gdb --pid `pidof ksmserver`"
> 3.) Type "c" to continue execution and press <return>, then switch back to
> the graphical TDE session and trigger the crash by logging out or whatever
> is needed.
> 4.) If ksmserver crashes the session will probably appear to hang instead of
> popping up a crash handler dialog.  If this happens switch back to the text
> console you were running gdb on and enter "bt" <return>.  Post the output to
> this report (if you can do the text mode portion over ssh you can copy +
> paste the output, otherwise attach a picture to this report).

Is it possible to pipe the output of gdb to a text file? Currently, I don't have a working camera, I don't have another machine from which to do ssh, and I am unaware of any other way to retrieve output from text-mode.

(In reply to Kristopher from comment #6)
> (In reply to Timothy Pearson from comment #5)
> > Ah, sorry--one of the other developers (Slavek Banko) put up a more stable
> > PPA for R14 as the nightly builds have been broken more often than not for
> > the past few months.
> > 
> > I haven't seen these crashes on my test boxes, however if you want to help
> > you can probably generate a backtrace this way:
> > 1.) Log in to TDE
> > 2.) Log in to a text-mode console, then attach GDB to the running ksmserver
> > process with "gdb --pid `pidof ksmserver`"
> > 3.) Type "c" to continue execution and press <return>, then switch back to
> > the graphical TDE session and trigger the crash by logging out or whatever
> > is needed.
> > 4.) If ksmserver crashes the session will probably appear to hang instead of
> > popping up a crash handler dialog.  If this happens switch back to the text
> > console you were running gdb on and enter "bt" <return>.  Post the output to
> > this report (if you can do the text mode portion over ssh you can copy +
> > paste the output, otherwise attach a picture to this report).
> 
> Is it possible to pipe the output of gdb to a text file? Currently, I don't
> have a working camera, I don't have another machine from which to do ssh,
> and I am unaware of any other way to retrieve output from text-mode.

You can ignore this question, I had a brainfart last night and forgot I could run multiple X.org sessions. I'll try to get the gdb output next time it crashes.

Created attachment 2344 [details]
gdb backtrace

The crash had already occurrend when I attached gdb to the process to obtain this backtrace, so I don't know if it will be as useful as it should be. At least I grabbed the backtrace before allowing the TDE Crash Handler to close and kill the process.

(In reply to Kristopher from comment #8)
> Created attachment 2344 [details]
> gdb backtrace
> 
> The crash had already occurrend when I attached gdb to the process to obtain
> this backtrace, so I don't know if it will be as useful as it should be. At
> least I grabbed the backtrace before allowing the TDE Crash Handler to close
> and kill the process.

Yep, that backtrace was quite helpful.

In a nutshell you hit yet another unfixed KDE bug:
https://bugs.kde.org/show_bug.cgi?id=282441

(In reply to Timothy Pearson from comment #9)
> (In reply to Kristopher from comment #8)
> Yep, that backtrace was quite helpful.
> 
> In a nutshell you hit yet another unfixed KDE bug:
> https://bugs.kde.org/show_bug.cgi?id=282441

Erm... the link points to a KDE4 bug filed years after KDE3 was discontinued, and this bug did not exist in 3.5.13.2 and early (or at least, I never saw it until a couple weeks prior to filing this bug).

(In reply to Kristopher from comment #10)
> (In reply to Timothy Pearson from comment #9)
> > (In reply to Kristopher from comment #8)
> > Yep, that backtrace was quite helpful.
> > 
> > In a nutshell you hit yet another unfixed KDE bug:
> > https://bugs.kde.org/show_bug.cgi?id=282441
> 
> Erm... the link points to a KDE4 bug filed years after KDE3 was
> discontinued, and this bug did not exist in 3.5.13.2 and early (or at least,
> I never saw it until a couple weeks prior to filing this bug).

There are lots of similar bugs; my main point is something is not quite stable in libICE and it seems to be somewhat machine-dependent; e.g. I have never seen this crash on my development systems.

I am now getting this bug on CentOS 7 running R14 stable. This is on a server (rather than my laptop, as was the case with the original report). I will attach a backtrace from the CentOS version, hopefully it will provide more information.

If you need more information from the CentOS machine, please ask quickly as I may not have it much longer (I am setting it up for a client).

Created attachment 2417 [details]
Backtrace from CentOS 7

What I could really use is a backtrace with the libICE and libSM debug symbols installed.  This crash occurs so rarely for me (< 1 of every 100 logouts) that I am having great difficulty figuring out what triggers it.

What frequency are you seeing?

Thanks!

(In reply to Timothy Pearson from comment #14)
> What I could really use is a backtrace with the libICE and libSM debug
> symbols installed.  This crash occurs so rarely for me (< 1 of every 100
> logouts) that I am having great difficulty figuring out what triggers it.

I've installed debug packages for libICE and libSM on both CentOS and Debian, I'll get the backtrace as soon as one of them crashes.

> What frequency are you seeing?

It can be somewhat sporadic, anywhere from every logout to once every 10 logouts.

Created attachment 2418 [details]
CentOS backtrace with libICE and libSD debug symbols

As mentioned in the attachment description, this is from CentOS with the libICE and libSD debugging packages installed.

A strange occurrence is that the TDE Crash Handler produced the last CentOS backtrace I submitted, but installing the debugging packages for this backtrace seems to render the TDE Crash Handler unable to produce a valid backtrace, similar to my report in bug 2227 ; the key difference is that I don't see any messages in the backtrace about CRC mismatches (or any other type of checksum issue).

(In reply to Kristopher from comment #15)
> (In reply to Timothy Pearson from comment #14)
> > What I could really use is a backtrace with the libICE and libSM debug
> > symbols installed.  This crash occurs so rarely for me (< 1 of every 100
> > logouts) that I am having great difficulty figuring out what triggers it.
> 
> I've installed debug packages for libICE and libSM on both CentOS and
> Debian, I'll get the backtrace as soon as one of them crashes.

Sounds good.  I ran ksmserver through Valgrind but other than a small internal bug in libSM/libICE nothing relevant appeared.  The sporadic nature of the problem is also curious as ksmserver is single threaded.

> > What frequency are you seeing?
> 
> It can be somewhat sporadic, anywhere from every logout to once every 10
> logouts.

Huh, that's at least an order of magnitude higher than my test box.  If I may ask:
1.) What widget style do you use?
2.) Do you have any applications running when you log out and ksmserver crashes?  If so, which ones?
3.) Does the number of CPU cores in the machine seem to influence the frequency of the crashes?  (I know ksmserver is not threaded, but I am starting to wonder if libICE's operation is somehow influenced by the threading of other applications that use it).

Thanks!

(In reply to Kristopher from comment #16)
> Created attachment 2418 [details]
> CentOS backtrace with libICE and libSD debug symbols
> 
> As mentioned in the attachment description, this is from CentOS with the
> libICE and libSD debugging packages installed.

Thanks, now we're getting somewhere. :-)  I'll look into the code to see if this sheds some light on the problem.

In the future, please generate backtraces manually with:
thread apply all bt

That way I can tell at a glance how many threads are in use and what state they are all in.  It doesn't matter as much here as (AFAIK) ksmserver is single-threaded, but there are applications where using that command would make the difference between being able to debug and not.

> A strange occurrence is that the TDE Crash Handler produced the last CentOS
> backtrace I submitted, but installing the debugging packages for this
> backtrace seems to render the TDE Crash Handler unable to produce a valid
> backtrace, similar to my report in bug 2227 ; the key difference is that I
> don't see any messages in the backtrace about CRC mismatches (or any other
> type of checksum issue).

Interesting.  I wonder if this line is causing issues?

Missing separate debuginfos, use: debuginfo-install dbus-libs-1.6.12-8.el7.x86_64 expat-2.1.0-8.el7.x86_64 file-libs-5.11-21.el7.x86_64 fontconfig-2.10.95-7.el7.x86_64 freetype-2.4.11-9.el7.x86_64 gamin-0.1.10-16.el7.x86_64 glib2-2.36.3-5.el7.x86_64 glibc-2.17-55.el7_0.3.x86_64 libX11-1.6.0-2.1.el7.x86_64 libXau-1.0.8-2.1.el7.x86_64 libXcomposite-0.4.4-4.1.el7.x86_64 libXcursor-1.1.14-2.1.el7.x86_64 libXext-1.3.2-2.1.el7.x86_64 libXfixes-5.0.1-2.1.el7.x86_64 libXft-2.3.1-5.1.el7.x86_64 libXi-1.7.2-2.1.el7.x86_64 libXinerama-1.1.3-2.1.el7.x86_64 libXrandr-1.4.1-2.1.el7.x86_64 libXrender-0.9.8-2.1.el7.x86_64 libacl-2.2.51-12.el7.x86_64 libattr-2.4.46-12.el7.x86_64 libgcc-4.8.2-16.2.el7_0.x86_64 libidn-1.28-3.el7.x86_64 libjpeg-turbo-1.2.90-5.el7.x86_64 libmng-1.0.10-14.el7.x86_64 libpng-1.5.13-5.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 libstdc++-4.8.2-16.2.el7_0.x86_64 libuuid-2.23.2-16.el7.x86_64 libxcb-1.9-5.el7.x86_64 pcre-8.32-12.el7.x86_64 systemd-libs-208-11.el7_0.6.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64

Thanks!

(In reply to Timothy Pearson from comment #17)
<snip>
> Huh, that's at least an order of magnitude higher than my test box.  If I
> may ask:
> 1.) What widget style do you use?

In Debian, I'm using Crystal. In CentOS, I'm using Plastik.

> 2.) Do you have any applications running when you log out and ksmserver
> crashes?  If so, which ones?

In both Debian and CentOS, I'm running Kmix and Klipper. In Debian only, I'm running TDE Powersave, wpa_gui, KGPG, KNotes, and HPLIP's system tray manager. In addition, the crash will *sometimes* occur with some other application, such as Firefox, Qupzilla, and/or something else running, however the crash will occur regardless of whether or not something else is running.

> 3.) Does the number of CPU cores in the machine seem to influence the
> frequency of the crashes?  (I know ksmserver is not threaded, but I am
> starting to wonder if libICE's operation is somehow influenced by the
> threading of other applications that use it).

I can't answer that as both CPUs are quadcore with hyperthreading (as in, two threads on every core), and I'm not running via virtual machine (which, unfortunately, is out of the questions unless R14 is available for CentOS 4, since my only remaining personal hard disk crashed).

(In reply to Timothy Pearson from comment #18)
> (In reply to Kristopher from comment #16)
> > Created attachment 2418 [details]
> > CentOS backtrace with libICE and libSD debug symbols
> > 
> > As mentioned in the attachment description, this is from CentOS with the
> > libICE and libSD debugging packages installed.
> 
> Thanks, now we're getting somewhere. :-)  I'll look into the code to see if
> this sheds some light on the problem.
> 
> In the future, please generate backtraces manually with:
> thread apply all bt
> 
> That way I can tell at a glance how many threads are in use and what state
> they are all in.  It doesn't matter as much here as (AFAIK) ksmserver is
> single-threaded, but there are applications where using that command would
> make the difference between being able to debug and not.
<snip>

Will that be useful for this bug report? If so, I can regenerate the backtrace next time the crash occurs.

Created attachment 2419 [details]
Debug ksmserver ICE structure destructors

(In reply to Kristopher from comment #20)
> (In reply to Timothy Pearson from comment #18)
> > (In reply to Kristopher from comment #16)
> > > Created attachment 2418 [details]
> > > CentOS backtrace with libICE and libSD debug symbols
> > > 
> > > As mentioned in the attachment description, this is from CentOS with the
> > > libICE and libSD debugging packages installed.
> > 
> > Thanks, now we're getting somewhere. :-)  I'll look into the code to see if
> > this sheds some light on the problem.
> > 
> > In the future, please generate backtraces manually with:
> > thread apply all bt
> > 
> > That way I can tell at a glance how many threads are in use and what state
> > they are all in.  It doesn't matter as much here as (AFAIK) ksmserver is
> > single-threaded, but there are applications where using that command would
> > make the difference between being able to debug and not.
> <snip>
> 
> Will that be useful for this bug report? If so, I can regenerate the
> backtrace next time the crash occurs.

Possibly, though it would be far more useful if you could rebuild/reinstall tdebase (well, just ksmserver) with the attached patch, logout/login and post the output in ~/.xsession_errors after a crash.  The patch adds debugging into the ICE structure destruction code and will let me see if we are looking at a double-free issue or something else.

Thanks!

(In reply to Timothy Pearson from comment #21)
> Created attachment 2419 [details]
> Debug ksmserver ICE structure destructors
> 
> (In reply to Kristopher from comment #20)
> > (In reply to Timothy Pearson from comment #18)
> > > (In reply to Kristopher from comment #16)
> > > > Created attachment 2418 [details]
> > > > CentOS backtrace with libICE and libSD debug symbols
> > > > 
> > > > As mentioned in the attachment description, this is from CentOS with the
> > > > libICE and libSD debugging packages installed.
> > > 
> > > Thanks, now we're getting somewhere. :-)  I'll look into the code to see if
> > > this sheds some light on the problem.
> > > 
> > > In the future, please generate backtraces manually with:
> > > thread apply all bt
> > > 
> > > That way I can tell at a glance how many threads are in use and what state
> > > they are all in.  It doesn't matter as much here as (AFAIK) ksmserver is
> > > single-threaded, but there are applications where using that command would
> > > make the difference between being able to debug and not.
> > <snip>
> > 
> > Will that be useful for this bug report? If so, I can regenerate the
> > backtrace next time the crash occurs.
> 
> Possibly, though it would be far more useful if you could rebuild/reinstall
> tdebase (well, just ksmserver) with the attached patch, logout/login and
> post the output in ~/.xsession_errors after a crash.  The patch adds
> debugging into the ICE structure destruction code and will let me see if we
> are looking at a double-free issue or something else.

If the .spec file for the CentOS package is available somewhere, I can do that fairly quickly since I'm comfortable with RPM and I can do package rebuilds and package swapping fairly easily on that system. I'll be doing a lot of work on that machine anyways, so it would be easier to do it there than to alternate systems. (I can't risk doing anything outside the package manager, keeping the entire system consistent and stable is crucial for my client)

Otherwise, it could take awhile (possibly until the weekend) on my Debian installation, unfortunately this is a busy week for me to have much time and patience for my slow flash drive (yes, I can do it if the CentOS option is out).

(In reply to Kristopher from comment #22)
> If the .spec file for the CentOS package is available somewhere, I can do
> that fairly quickly since I'm comfortable with RPM and I can do package
> rebuilds and package swapping fairly easily on that system. I'll be doing a
> lot of work on that machine anyways, so it would be easier to do it there
> than to alternate systems. (I can't risk doing anything outside the package
> manager, keeping the entire system consistent and stable is crucial for my
> client)

I'd imagine the CentOS packages were built using the .spec files in our packaging repository, but I don't know for sure as I don't handle the RPM builds. :-)

https://git.trinitydesktop.org/cgit/tde-packaging/tree/

(In reply to Timothy Pearson from comment #23)
> (In reply to Kristopher from comment #22)
> > If the .spec file for the CentOS package is available somewhere, I can do
> > that fairly quickly since I'm comfortable with RPM and I can do package
> > rebuilds and package swapping fairly easily on that system. I'll be doing a
> > lot of work on that machine anyways, so it would be easier to do it there
> > than to alternate systems. (I can't risk doing anything outside the package
> > manager, keeping the entire system consistent and stable is crucial for my
> > client)
> 
> I'd imagine the CentOS packages were built using the .spec files in our
> packaging repository, but I don't know for sure as I don't handle the RPM
> builds. :-)
> 
> https://git.trinitydesktop.org/cgit/tde-packaging/tree/

It would seem that whoever does handle the RPM packages has forgotten to upload SRPMs (Source RPMs) for the CentOS/RHEL build of TDE. It's not a big issue, I can manually set up my build environment and adjust the .spec file to accommodate, however this will delay the rebuild and new backtrace a bit owing to the fact that I don't have the convenience of a SRPM to automagically set up the build environment for me.

(In reply to Kristopher from comment #24)
> (In reply to Timothy Pearson from comment #23)
> > (In reply to Kristopher from comment #22)
> > > If the .spec file for the CentOS package is available somewhere, I can do
> > > that fairly quickly since I'm comfortable with RPM and I can do package
> > > rebuilds and package swapping fairly easily on that system. I'll be doing a
> > > lot of work on that machine anyways, so it would be easier to do it there
> > > than to alternate systems. (I can't risk doing anything outside the package
> > > manager, keeping the entire system consistent and stable is crucial for my
> > > client)
> > 
> > I'd imagine the CentOS packages were built using the .spec files in our
> > packaging repository, but I don't know for sure as I don't handle the RPM
> > builds. :-)
> > 
> > https://git.trinitydesktop.org/cgit/tde-packaging/tree/
> 
> It would seem that whoever does handle the RPM packages has forgotten to
> upload SRPMs (Source RPMs) for the CentOS/RHEL build of TDE. It's not a big
> issue, I can manually set up my build environment and adjust the .spec file
> to accommodate, however this will delay the rebuild and new backtrace a bit
> owing to the fact that I don't have the convenience of a SRPM to
> automagically set up the build environment for me.

Hmmm, sounds like something that should be mentioned on the mailing list.  IIRC Francois Androit handles the RPM builds.

Tim

Created attachment 2420 [details]
CentOS backtrace with ICE patch and libICE/libSD debug symbols

After a bit of muddying around to set up my build environment, I applied your patch to the stable R14 release of the tdebase source tarballs, removed the existing TDE packages, and installed all the resulting RPM packages from the patched tdebase. All settings are exactly the same, I did *not* remove the existing ~/.trinity/ directory.

(In reply to Kristopher from comment #26)
> Created attachment 2420 [details]
> CentOS backtrace with ICE patch and libICE/libSD debug symbols
> 
> After a bit of muddying around to set up my build environment, I applied
> your patch to the stable R14 release of the tdebase source tarballs, removed
> the existing TDE packages, and installed all the resulting RPM packages from
> the patched tdebase. All settings are exactly the same, I did *not* remove
> the existing ~/.trinity/ directory.

I need the ~/.xsession_errors file from the crash as well.

Thanks!

(In reply to Timothy Pearson from comment #27)
> (In reply to Kristopher from comment #26)
> > Created attachment 2420 [details]
> > CentOS backtrace with ICE patch and libICE/libSD debug symbols
> > 
> > After a bit of muddying around to set up my build environment, I applied
> > your patch to the stable R14 release of the tdebase source tarballs, removed
> > the existing TDE packages, and installed all the resulting RPM packages from
> > the patched tdebase. All settings are exactly the same, I did *not* remove
> > the existing ~/.trinity/ directory.
> 
> I need the ~/.xsession_errors file from the crash as well.
> 
> Thanks!

That would be a problem since I logged back in right after that crash in order to submit the backtrace. The .xsession_errors does not appear to contain any information from the crash from the previous login.

(In reply to Kristopher from comment #28)
> (In reply to Timothy Pearson from comment #27)
> > (In reply to Kristopher from comment #26)
> > > Created attachment 2420 [details]
> > > CentOS backtrace with ICE patch and libICE/libSD debug symbols
> > > 
> > > After a bit of muddying around to set up my build environment, I applied
> > > your patch to the stable R14 release of the tdebase source tarballs, removed
> > > the existing TDE packages, and installed all the resulting RPM packages from
> > > the patched tdebase. All settings are exactly the same, I did *not* remove
> > > the existing ~/.trinity/ directory.
> > 
> > I need the ~/.xsession_errors file from the crash as well.
> > 
> > Thanks!
> 
> That would be a problem since I logged back in right after that crash in
> order to submit the backtrace. The .xsession_errors does not appear to
> contain any information from the crash from the previous login.

Hmmm, OK.  Can you crash it again and, before logging back in, copy the ~/.xsession_errors file somewhere safe for submission?

On Debian the ~/.xsesssion_errors file is appended to on each login; is CentOS different?

I am looking for the [DEBUG nnn.n xxx] output lines specifically.

Tim

Created attachment 2421 [details]
~/xsession-errors

I've censored my client's information for privacy's sake (the "(censored)" bits where the user name and hostname should be), otherwise the file is unchanged.

(In reply to Timothy Pearson from comment #29)
> (In reply to Kristopher from comment #28)
> > (In reply to Timothy Pearson from comment #27)
<snip>
> > > I need the ~/.xsession_errors file from the crash as well.
> > > 
> > > Thanks!
> > 
> > That would be a problem since I logged back in right after that crash in
> > order to submit the backtrace. The .xsession_errors does not appear to
> > contain any information from the crash from the previous login.
> 
> Hmmm, OK.  Can you crash it again and, before logging back in, copy the
> ~/.xsession_errors file somewhere safe for submission?

Attached.

> On Debian the ~/.xsesssion_errors file is appended to on each login; is
> CentOS different?
<snip>

Unless it's different on the version of Debian you're using, this has never been the case -- at least, not in Lenny, Squeeze, or Wheezy (admittedly the only versions I've used): all three have always replaced my ~/.xsession-errors file on each login, as does CentOS.

Created attachment 2422 [details]
Example xsession_errors output with debugging enabled

(In reply to Kristopher from comment #30)
> Created attachment 2421 [details]
> ~/xsession-errors
> 
> I've censored my client's information for privacy's sake (the "(censored)"
> bits where the user name and hostname should be), otherwise the file is
> unchanged.

Unfortunately that file does not contain the debugging information.  Are you sure you applied the patch and installed the rebuilt ksmserver?

See attachment for the general idea of what I would like to see; note in particular all the DEBUG lines.

(In reply to Kristopher from comment #31)
> Unless it's different on the version of Debian you're using, this has never
> been the case -- at least, not in Lenny, Squeeze, or Wheezy (admittedly the
> only versions I've used): all three have always replaced my
> ~/.xsession-errors file on each login, as does CentOS.

I'm using Debian Jessie on my development box; perhaps that's why I'm seeing the append behaviour.

(In reply to Timothy Pearson from comment #32)
> Created attachment 2422 [details]
> Example xsession_errors output with debugging enabled
> 
> (In reply to Kristopher from comment #30)
> > Created attachment 2421 [details]
> > ~/xsession-errors
> > 
> > I've censored my client's information for privacy's sake (the "(censored)"
> > bits where the user name and hostname should be), otherwise the file is
> > unchanged.
> 
> Unfortunately that file does not contain the debugging information.  Are you
> sure you applied the patch and installed the rebuilt ksmserver?
> 
> See attachment for the general idea of what I would like to see; note in
> particular all the DEBUG lines.
<snip>

I am sure I did apply the patch and installed the patched packages.

(In reply to Kristopher from comment #33)
> (In reply to Timothy Pearson from comment #32)
> > Created attachment 2422 [details]
> > Example xsession_errors output with debugging enabled
> > 
> > (In reply to Kristopher from comment #30)
> > > Created attachment 2421 [details]
> > > ~/xsession-errors
> > > 
> > > I've censored my client's information for privacy's sake (the "(censored)"
> > > bits where the user name and hostname should be), otherwise the file is
> > > unchanged.
> > 
> > Unfortunately that file does not contain the debugging information.  Are you
> > sure you applied the patch and installed the rebuilt ksmserver?
> > 
> > See attachment for the general idea of what I would like to see; note in
> > particular all the DEBUG lines.
> <snip>
> 
> I am sure I did apply the patch and installed the patched packages.

This doesn't make sense; you should be seeing those DEBUG lines in your session output per my example if the patch was applied and installed.  Does CentOS do anything differently regarding routing the output of ksmserver to some other file?

(In reply to Timothy Pearson from comment #34)
> (In reply to Kristopher from comment #33)
> > (In reply to Timothy Pearson from comment #32)
> > > Created attachment 2422 [details]
> > > Example xsession_errors output with debugging enabled
> > > 
> > > (In reply to Kristopher from comment #30)
> > > > Created attachment 2421 [details]
> > > > ~/xsession-errors
> > > > 
> > > > I've censored my client's information for privacy's sake (the "(censored)"
> > > > bits where the user name and hostname should be), otherwise the file is
> > > > unchanged.
> > > 
> > > Unfortunately that file does not contain the debugging information.  Are you
> > > sure you applied the patch and installed the rebuilt ksmserver?
> > > 
> > > See attachment for the general idea of what I would like to see; note in
> > > particular all the DEBUG lines.
> > <snip>
> > 
> > I am sure I did apply the patch and installed the patched packages.
> 
> This doesn't make sense; you should be seeing those DEBUG lines in your
> session output per my example if the patch was applied and installed.  Does
> CentOS do anything differently regarding routing the output of ksmserver to
> some other file?

That's better asked to someone more intimately familiar with CentOS packages, but I doubt they'd interfere with the normal functioning of Xorg and the DE's and WM's that run on top of it considering that could interfere with debugging stuff when problems occurs.

Created attachment 2424 [details]
Another ~/.xsession-errors snapshot

Hopefully this one is good. This was grabbed after a complete removal and purging of all TDE packages and configuration, including /root/.trinity and the user's ~/.trinity , followed by a rebuild of the patched packages.

(In reply to Kristopher from comment #36)
> Created attachment 2424 [details]
> Another ~/.xsession-errors snapshot
> 
> Hopefully this one is good. This was grabbed after a complete removal and
> purging of all TDE packages and configuration, including /root/.trinity and
> the user's ~/.trinity , followed by a rebuild of the patched packages.

Yep, perfect, thanks!  I'll analyze this in my next chunk of free time.

(In reply to Timothy Pearson from comment #37)
> (In reply to Kristopher from comment #36)
> > Created attachment 2424 [details]
> > Another ~/.xsession-errors snapshot
> > 
> > Hopefully this one is good. This was grabbed after a complete removal and
> > purging of all TDE packages and configuration, including /root/.trinity and
> > the user's ~/.trinity , followed by a rebuild of the patched packages.
> 
> Yep, perfect, thanks!  I'll analyze this in my next chunk of free time.

Sorry for the delay in response.  Thanks to the information you were able to provide I was able to track this down to a duplicate call to  IceCloseConnection() under certain (rare) conditions.

This should be fixed in GIT hash 9005480.

Thanks for reporting, and for working with me on the fix!

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

Hi all,

Just to provide a few more detail:
1.This bug happens too on PCLinuxOS 2014 with R14.0.0 final release (This was one of the main reasons I have not built my remaster with R14 yet)
2.When the TDE debug box appear. I couldn't type my root password, to get TDE to launch GDB, except maybe 2% of the time I tried to plug a usb keyboard to see if it would work, but it didn't work)
3.Maybe 1% of the time, the logout process worked without bug, but I have not been able to identify why.

Great to hear that this bug is resolved! I'll test it in the next few days.

Thanks!
-Alexandre

Hi,

Ok, I confirm that this bug is solved on my system.Thank!

-Alexandre