I am seeing the same issue here, however, it does not happen every time, only about every third or fourth time.

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

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

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

Can confirm this is also happening on Fedora 22, the following is my package info

$ rpm -qa | egrep "nvidia|konsole|kf5-framework"
xorg-x11-drv-nvidia-libs-355.11-1.fc22.i686
xorg-x11-drv-nvidia-355.11-1.fc22.x86_64
akmod-nvidia-355.11-4.fc22.x86_64
kf5-frameworkintegration-5.15.0-1.fc22.x86_64
xorg-x11-drv-nvidia-libs-355.11-1.fc22.x86_64
xorg-x11-drv-nvidia-kmodsrc-355.11-1.fc22.x86_64
kmod-nvidia-4.2.3-200.fc22.x86_64-355.11-4.fc22.x86_64
konsole5-part-15.08.1-1.fc22.x86_64
konsole5-15.08.1-1.fc22.x86_64
xorg-x11-drv-nvidia-cuda-355.11-1.fc22.x86_64
konsole-part-4.14.3-4.fc22.x86_64
kf5-frameworkintegration-libs-5.15.0-1.fc22.x86_64

Latest Fedora / KDE / Nvidia updates do not solve this issue yet:

$ rpm -qa | egrep "nvidia|konsole|kf5-framework"
konsole5-15.08.3-1.fc23.x86_64
kf5-frameworkintegration-5.16.0-1.fc23.x86_64
akmod-nvidia-358.16-1.fc23.x86_64
kmod-nvidia-4.2.6-300.fc23.x86_64-358.16-1.fc23.x86_64
konsole5-part-15.08.3-1.fc23.x86_64
xorg-x11-drv-nvidia-libs-358.16-1.fc23.x86_64
xorg-x11-drv-nvidia-libs-358.16-1.fc23.i686
xorg-x11-drv-nvidia-358.16-1.fc23.x86_64
kf5-frameworkintegration-libs-5.16.0-1.fc23.x86_64
kmod-nvidia-4.2.5-300.fc23.x86_64-358.16-1.fc23.x86_64
xorg-x11-drv-nvidia-kmodsrc-358.16-1.fc23.x86_64

I think we have enough dups to considure this confirmed

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

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

Same problem here on Manjaro. This bug report seems to be a duplicate https://bugs.kde.org/show_bug.cgi?id=344119

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

In KDE5: If I make many connection by ssh and live konsole to the night, at morning it hangs, absolutely.

OpenSuse Tumbleweed.
Konsole no close
System not shutdown. KsmServer cpu usage.

Confirmed in openSuse Leap.

It first has been reported 10 month ago. Can we have this fixed please or at least some infos ;)

The hang is presumably in nvidia libs, has anyone reported this to them?

Here it happens only sometimes.
But 2 things:

starting Konsole from a xterm:

QCoreApplication::arguments: Please instantiate the QApplication object first
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.

I'm trying with strace but obviosly, does not happens with strace but the last line is:
+++ exited with 0 +++

Why "exited with 0 " ? Just started and running..

Konsole-15.08

Sometimes konsole crashes on exit and drkonqui shows this developer information.

Application: Konsole (konsole), signal: Aborted
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f947f437880 (LWP 2298))]

Thread 2 (Thread 0x7f9468a25700 (LWP 2299)):
[KCrash Handler]
#5  0x00007f947ed8c5f8 in raise () from /usr/lib/libc.so.6
#6  0x00007f947ed8da7a in abort () from /usr/lib/libc.so.6
#7  0x00007f947edcb05a in __libc_message () from /usr/lib/libc.so.6
#8  0x00007f947edd09a6 in malloc_printerr () from /usr/lib/libc.so.6
#9  0x00007f947edd0c39 in malloc_consolidate () from /usr/lib/libc.so.6
#10 0x00007f947edd28a0 in _int_malloc () from /usr/lib/libc.so.6
#11 0x00007f947edd4eca in calloc () from /usr/lib/libc.so.6
#12 0x00007f9470dd43e3 in ?? () from /usr/lib/libnvidia-tls.so.358.16
#13 0x00007f9475643381 in g_malloc0 () from /usr/lib/libglib-2.0.so.0
#14 0x00007f947565aead in g_slice_free1 () from /usr/lib/libglib-2.0.so.0
#15 0x00007f9475d70579 in __nptl_deallocate_tsd.part.4 () from /usr/lib/libpthread.so.0
#16 0x00007f9475d71658 in start_thread () from /usr/lib/libpthread.so.0
#17 0x00007f947ee4213d in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7f947f437880 (LWP 2298)):
#0  0x00007f9470dd2e15 in _nv014tls () from /usr/lib/libnvidia-tls.so.358.16
#1  0x00007f9474cc1bad in ?? () from /usr/lib/libGL.so.1
#2  0x00007f9474cc1f78 in ?? () from /usr/lib/libGL.so.1
#3  0x00007f9474cc206a in ?? () from /usr/lib/libGL.so.1
#4  0x00007f9474d05365 in ?? () from /usr/lib/libGL.so.1
#5  0x00007f947f340885 in _dl_fini () from /lib64/ld-linux-x86-64.so.2
#6  0x00007f947ed8ef88 in __run_exit_handlers () from /usr/lib/libc.so.6
#7  0x00007f947ed8efd5 in exit () from /usr/lib/libc.so.6
#8  0x00007f947ed79617 in __libc_start_main () from /usr/lib/libc.so.6
#9  0x0000000000400779 in _start ()

(In reply to Rex Dieter from comment #16)
> The hang is presumably in nvidia libs, has anyone reported this to them?
Someone reported this on some nVidia forum: https://devtalk.nvidia.com/default/topic/879586/kf5-konsole-15-04-and-15-08-consumes-100-cpu-on-close-only-with-proprietary-nvidia-driver/


Bug 343347 is probably a duplicate

Hi all, 

I have noticed that in my machine this bug always happens when I close konsole through the usual "close" icon of the window decoration; however, if I close the konsole closing all the tabs with the "close tab" button, then it never happens.

Another notice : 
I use also xfce, and if I use the konsole with xfce, I have the problem.
But if I use the console of xfce (Terminal Xfce) on kde, no problem.

I think it's not really a problem with nvidia but a problem with kde.

That make bad press and bad feeling about the Plasma 5 desktop... 

https://youtu.be/E02gHmG61ro?t=1h4m55s

I really don't know where the problem lies but it will be surprising if it's a Nvidia problem because others programs works fine. It's more likely a Konsole / KF5 problem.

re: comment #22

No reason to say "I really don't know", we do know.  It's hanging inside one of nvidia's libraries.  that makes it pretty clear where the problem is.

In reply to Rex Dieter from comment #16)
> The hang is presumably in nvidia libs, has anyone reported this to them?

(In reply to Rex Dieter from comment #23)
> re: comment #22
> No reason to say "I really don't know", we do know.  It's hanging inside one
> of nvidia's libraries.  that makes it pretty clear where the problem is.

Ok so for you "presumably" = "we know for sure why that don't work" ? If that's the case can you tell us if that need to be fixed in Konsole, KF5, Nvidia driver or anything else ?

Why Deepin Terminal don't have any problems with Nvidia?

It's (virtually) impossible to debug nvidia's libs, no debuginfo or source code.

(In reply to Rex Dieter from comment #26)
> It's (virtually) impossible to debug nvidia's libs, no debuginfo or source
> code.

As you can see, the problem has been reported to Nvidia without success for now. Maybe if you and the other comment there we can make things move. Plasma 5 can't stay with this problem.

https://devtalk.nvidia.com/default/topic/879586/kf5-konsole-15-04-and-15-08-consumes-100-cpu-on-close-only-with-proprietary-nvidia-driver/

We really don't know anything about where the issue is. All we know is that a function from the nvidia driver is getting called repeatedly, and that's where CPU time is going. I can easily invent a dozen scenarios that would cause this type of behaviour, yet it would still be my fault (the simplest being to just call whatever driver function in an infinite loop.)

Seeing how the nvidia driver is generally very solidly engineered (the most reliable of all drivers by a HUGE margin, in my experience) I see no particular reason to assume it's the drivers fault.

What evidence do you have that the nvidia function is getting called repeatedly?

In the backtrace I observed, it was called once, then stuck/hung.

(In reply to ufoscout from comment #20)
> Hi all, 
> 
> I have noticed that in my machine this bug always happens when I close
> konsole through the usual "close" icon of the window decoration; however, if
> I close the konsole closing all the tabs with the "close tab" button, then
> it never happens.
I can confirm this behavior. Thanks for sharing, it's a good workaround for now.

I believe I observed the breakpoint being triggered many times, but I'm not sure how thoroughly I actually investigated that. I can collect more data later today to (hopefully) answer the question definitely.

If it does indeed just hang in the  nvidia function without ever returning to konsoles code, then I would agree that that makes it a much more likely candidate for being a bug in the driver; but that's still not entirely a sure thing.

I can try to make a debug-build of konsole to isolate the driver<->konsole transitioning site, but I'm not sure if I'll have time this week.

> I can collect more data later today to (hopefully) answer the question definitely.
> I can try to make a debug-build of konsole to isolate the driver<->konsole transitioning site

That's sound very good. Thank you very much.

> but I'm not sure if I'll have time this week.

Take your time, the simple fact that we know that is investigated reassure us and give us hope for a fix ;)

These seems to be duplicates :
bug 350475, bug 354965, bug 351587

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

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

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

(In reply to Jonathan Ringstad from comment #31)
> I believe I observed the breakpoint being triggered many times, but I'm not
> sure how thoroughly I actually investigated that. I can collect more data
> later today to (hopefully) answer the question definitely.
> 
> If it does indeed just hang in the  nvidia function without ever returning
> to konsoles code, then I would agree that that makes it a much more likely
> candidate for being a bug in the driver; but that's still not entirely a
> sure thing.
> 
> I can try to make a debug-build of konsole to isolate the driver<->konsole
> transitioning site, but I'm not sure if I'll have time this week.
Any news ?

OK so that won't be fixed anytime soon I guess.

I have seen this but sporadically, on openSUSE Tumbleweed

seems like we have to wait 10 years for a fix

I had a look and found a bit of additional information:

- The hang occurs when the libc exit handler cleans up the shared libraries of the program, so when the process starts to hang, no actual konsole code is running anymore. So that seems to make it very unlikely that the fault is with konsole
- the hang occurs inside _nv014tls in /usr/lib/libnvidia-tls.so.358.16 (nvidias thread-local storage library used by GL, GLX et al), where the function falls into an infinite loop. Injecting a debugger and forcing it to return, results in konsole exiting normally.
- The libc exit handler calls /usr/lib/libGL.so.1's .fini section (I think) which calls the problematic _nv014tls from the libnvidia-tls.so.
- libGL gets loaded because konsole (well, Qt, I think -- konsole does not touch GLX directly) wants to do glX* calls such as glXChooseFBConfig, glXGetFBConfigAttrib, glXGetVisualFromFBConfig. no GLX context is ever initialized or destroyed from what I can tell, however (which is a bit strange, but I think should be perfectly legal to do. All the functions that are called do not require a GLX context to be present, from what I can tell.)
- Re-running the exact same sequence of GLX functions in a different process does not lead to such a hang. Traceback: http://dpaste.com/0RWSDK7 I re-ran the traceback a few thousand times without a hang. So there's probably at least one more ingredient necessary to make the hang happen.

That's about as far as I got. As a workaround it might be possible to make Qt not interact with GLX (if that's possible), since it's not used anyway. It seems pretty likely to me at this point that the bug is in the nvidia client driver, but I suppose there is still a chance the bug is in Qt. I think the bug is definitely not in konsole.

I didn't manage to produce a minimal test-case, unfortunately. To get there, it might be useful to check if konsole loads any other nvidia client drivers, and if yes, how it interacts with them.

I had a look and found a bit of additional information:

- The hang occurs when the libc exit handler cleans up the shared libraries of the program, so when the process starts to hang, no actual konsole code is running anymore. So that seems to make it very unlikely that the fault is with konsole
- the hang occurs inside _nv014tls in /usr/lib/libnvidia-tls.so.358.16 (nvidias thread-local storage library used by GL, GLX et al), where the function falls into an infinite loop. Injecting a debugger and forcing it to return, results in konsole exiting normally.
- The libc exit handler calls /usr/lib/libGL.so.1's .fini section (I think) which calls the problematic _nv014tls from the libnvidia-tls.so.
- libGL gets loaded because konsole (well, Qt, I think -- konsole does not touch GLX directly) wants to do glX* calls such as glXChooseFBConfig, glXGetFBConfigAttrib, glXGetVisualFromFBConfig. no GLX context is ever initialized or destroyed from what I can tell, however (which is a bit strange, but I think should be perfectly legal to do. All the functions that are called do not require a GLX context to be present, from what I can tell.)
- Re-running the exact same sequence of GLX functions in a different process does not lead to such a hang. Traceback: http://dpaste.com/0RWSDK7 I re-ran the traceback a few thousand times without a hang. So there's probably at least one more ingredient necessary to make the hang happen.

That's about as far as I got. As a workaround it might be possible to make Qt not interact with GLX (if that's possible), since it's not used anyway. It seems pretty likely to me at this point that the bug is in the nvidia client driver, but I suppose there is still a chance the bug is in Qt. I think the bug is definitely not in konsole.

I didn't manage to produce a minimal test-case, unfortunately. To get there, it might be useful to check if konsole loads any other nvidia client drivers, and if yes, how it interacts with them.

> As a workaround it might be possible to make Qt not interact with GLX (if that's possible)

It is:
export QT_XCB_FORCE_SOFTWARE_OPENGL=1
but you folks should really use a working OpenGL driver instead (try Nouveau).

Though actually, QT_XCB_FORCE_SOFTWARE_OPENGL is probably also ineffective because the proprietary driver replaces the system libGL with its own version that probably does not support LIBGL_ALWAYS_SOFTWARE. So if it doesn't help, that'd be why.

That does indeed not fix the issue, as the issue is not with OpenGL but with GLX. The GLX calls are made all the same. 

You can force software rendering through mesas llvm-pipe by adjusting your library path to include the mesa libGL.so first (mesas llvm-pipe driver can pretty much co-exist with any other driver without big issues -- useful for testing), but that is a rather drastic measure and not a solution I would recommend for end-users as workaround for several reasons.

Dozens of app and it happens only with Konsole... strange..
Even yakuake5 is working fine.

This appears to be fixed in 361.18, can someone still reproduce it with this version? 

(They fixed a different Qt triggered bug in that release, might have been a similar or even the same cause)

(In reply to Fuchs from comment #47)
> This appears to be fixed in 361.18, can someone still reproduce it with this
> version? 
> 
> (They fixed a different Qt triggered bug in that release, might have been a
> similar or even the same cause)

Have they fixed all the problems 361.16 was having with KDE and Steam?  I'd rather click the lower right close button on a terminal than have my system unstable.

Also, 361.16 is still the latest in the ppa.  It'll be much easier to back out from a ppa install than manual install.  I'll wait until .18 is in the ppa to give it try.

A little off-topic, but I tested the issue I had with it crashing when restoring/backing-up games and it did not crash now with 361.16 on Fedora 23. 

I also have not experienced a konsole cpu lockup either. Looking good so far....

# for I in $(seq -w 1 100); do konsole -e sleep 2s; done

It seems konsole doesn't keep running in background after that. Not one single process, so looking good so far.

# cat /sys/module/nvidia/version 
361.18

# konsole -v 
QCoreApplication::arguments: Please instantiate the QApplication object first
Qt: 5.5.1
KDE Frameworks: 5.18.0
Konsole: 15.12.1

Just installed 361.18 now that it made it into the ppa.  All seems well after several Konsole sessions.

So if I use the 340.x driver, I'm out of luck?

Since this bug seems to be fixed with latest Nvidia drivers can someone take a look at this (small) bug please ?

"Terminal Size" setting in profile ignored
https://bugs.kde.org/show_bug.cgi?id=345403

And thanks for your work for trying to fix this bug even if (need to be confirmed by devs) it was in the Nvidia driver.

Thanks everyone for the testing, I'll take the liberty marking this resolved->upstream (ultimately nvidia issue)

Feel free to reopen if anyone has new information.

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

Hi Rex.
Just one question.
I am on fedora, Is the 361.18 driver is expected soon in rpmfusion?

I don't know, sorry

Same problem here.
Manjaro x86_64
Linux 4.4.1
KDE Plasma 5.5.4-1
NVIdia 352.63
Konsole uses 12% of my CPU. When I run multiple instances of Konsole, and close them using the close button on the window, it remains in the background. I use QTerminal instead, no issues. I wonder how that could be related to NVidia drivers.

Same here
Manjaro x86_64 
Linux 4.1
Nvidia 340 legacy driver
Konsole 15.12.1
Eats 1 core out of 8 which is 12%. 
I have old GPU and can't use new drivers so if this bug won't be fixed by KDE devs it will plague my laptop forever. 
Also using QTerminal without issues but haven't found how to fully integrate it into Dolphin.

This needs to be re-opened due to the fact that 361.28 has a regression that causes this bug to reappear. Unfortunately this is the new LONG-LIVED driver. :(

I can't duplicate this Mike.  I've tried a dozen or so konsoles, and not one of them hung.  Before, I wasn't able to open and close more than twice before one hung up.

Mike: My guess would be that it depends on whether you use the glvnd library or not. 

Could you try installing the driver with it and see if the problem persists? 
I can't reproduce it when using glvnd  (which, despite the problem it had, would be my recommendation)

It appears your hypothesis is correct, when I reinstalled the driver with: 

NVIDIA-Linux-x86_64-361.28.run -s --dkms --install-libglvnd --glvnd-glx-client

I am not able to reproduce the bug. I assume GLVND was by default in the beta?

This has been a problem on my OpenSUSE Leap 42.1, and I am using the Nvidia 361.48 driver which uses the legacy non-GLVND.
The Nvidia 364.x driver will make GLVND default, so if that will fix the problem all we have to do is wait until that version of the driver is released..

Unfortunately, my GeForce 9500M GS card on my laptop is too old to even have any options for GLVND for the latest driver available for it, v. 340.  I'm stuck with this bug.  Other than this issue with konsole, KDE Plasma 5 was exceptionally snappy.  It put Windows Vista to shame.  I'm saddened that I seem to have no workaround for this issue.  The new 364 driver does not support my card.  I could go back to the nouveau driver, but then I can't play some of my old video games.    

I could stop using konsole and switch to Gnome terminal or something else, but I like konsole's customization options for theming.  Also, I am worried that I will eventually run into this issue again with a different KDE application and not even realize that my CPU is burning up until it's too late.  The only reason I caught this was that I was monitoring resource usage after a fresh install of Kubuntu 16.04.

So, no, this issue is not resolved for me.  I'd like to stick with konsole if I can, and truly have a fix that works for my graphics card and will work for other applications that could have the same underlying problem.

Please consider reopening this issue.  It would be nice to find a workaround on the KDE side of things.

I re-found this issue on kubuntu 16.04 too.

Same issue here:  close Konsole using window 'X" and one processor goes up to 100%; have to kill it; if I close the last tab with it's 'local X' no problem; if I close using 'exit' at CL, no problem.

Older HP laptop; GeForce 8600M GS; nVidia patched 340.96 driver.

I understand this is really an nVidia issue but here's MY issue with KDE:  no other terminal program I use under KDE except Konsole has this problem, therefore, is this REALLY solely nVidia's issue or are 'you KDE folks' just kicking the turd down the road?  This has been going on for way too long (years, for crap's sake), how about you 'KDE folks' own up to it and fix it?  You're looking like a bunch of goofballs right now...

reopen, please

For 9600GT. install nvidia-experimental-340 solve this for my

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

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

Resolved ????!!!!
I also use Nvidia 340 drivers.
All these days after I installed the new Mint KDE 18 OS , I used to run the konsole to make my system better , to take updates , to fix my fstab ,etc etc and closing this application, I actually had less than the 50% of my CPU available…
Finally I noticed that konsole was running to the backround. Lucky me !!!
This is the main reason (I guess), I found plasma desktop very heavy and I wanted to change my desktop !!!
Because of a konsole with psychological problems…….
Thanks a lot for your understanding …..!

Another workaround.
The failure (at least in my case) occurs when the last instance of konsole closes. Then the solution is that there is always an instance of konsole in the session.

Add to the start of session: /usr/bin/konsole --background-mode

Am Dienstag, 27. September 2016, 10:08:17 CEST schrieb Fran via KDE Bugzilla:
> https://bugs.kde.org/show_bug.cgi?id=343803

One think, that should be noticed: The process "konsole", which is eating the 
whole cpu power is NOT the process of a running (manually started) process, 
but a NEW one! 

You can see it, when you have some (manually) konsole processes started, then 
start synaptic and close it with the "X". A NEW process appears. Close now 
your open konsoles (the windows) and you will see: The power eating process 
remains. 
It also happens, when you NEVER started konsole manually, also a new process 
"konsole" get started by using i.e. synaptic. (Must not be synaptic, sometimes 
other applications cause the same, but I see it mostly when using synaptics).

Best

Hans

Just tried the latest version (16.08.1).  The problem seems to have been resolved...FINALLY! HOORAH FOR THE 'KDE FOLKS'!!  Thanks...I think.

Herr Ullrich,

I don't know for sure but your input may have finally helped solve this years-long issue.

Vielen Dank!!

Just checked a konsole session this morning...the problem is still present.  Bummer.
Hans - you were correct!  Wishful thinking on my part that 'they' fixed it.

Yes, I can confirm, the bug is still existent. As I cannot change my nvidia drivers (as I need legacy drivers), they are still installed. So on my system KDE changed, but not the drivers.

Another hint: Maybe there is a relationship with another bug. I found out, that SDDM can not be started, when nvidia drivers are used. Just a thought, maybe there is a relationship somehow...

Best regards

Hans

I have started to see the issue on a Kubuntu Yakkety (16.10) machine that uses Nvidia Quadro FX 570 graphics. The graphics card is supported by the Nvidia 340 legacy driver. The software included in Yakkety is plasma 5.7.5, framework 5.26.0, konsole 16.04.3, QT 5.6.1.

The symptoms seem to be exactly those described here. Closing the konsole a process is left behind, in my case using 100% cpu. Furthermore, there are occasional crashes of the konsole on exit due to issues with corrupted double linked lists.

Moving to the noveau driver resolves both the issues (but brings in other problems on its own).

The interesting part is that the same machine with exactly the same hardware, was not showing this issue with ubuntu Xenial, while others report the issue also on Xenial.

I thus wonder if the bug may be triggered by some sort of race or ordering/timings in which events occur, that may be influenced by both the hardware and the software stack. If this is the case, the fixing of the issue in the most recent Nvidia drivers could be just luck. For sure, the issue is still present with the latest Nvidia 340 drivers, so please reopen.

Even if this is a bug with the Nvidia legacy opengl implementation, avoiding triggering the issue in the beginning in the konsole would be the best. This should be possible as the Qt terminal is reported not to have any issue.

Note that a comment in the bug thread on the nvidia bug tracker states: "From what I've seen it may not be the nVidia driver which is at fault. There seems to be a complicated threading issue which might or might not be caused by the driver...it may just be this driver exposes the issue differently."

The fact that some people saw the issue even in Xenial with Nvidia 340 and I did not, as well as the fact that some report that on more modern graphics cards the issue disappeared with nvidia 361.18 and reappeared in 361.28 seems to confirm that this may just be a race somewhere (Qt?) and not a bug in the nvidia drivers.

Is there a Qt bug open on this?

For the past weeks I messed around with this one and found out that if I open two different konsole instances, I could close them both without the cpu drainage. This might explain the complicated threading issue?
(In reply to Sergio from comment #80)
> Note that a comment in the bug thread on the nvidia bug tracker states:
> "From what I've seen it may not be the nVidia driver which is at fault.
> There seems to be a complicated threading issue which might or might not be
> caused by the driver...it may just be this driver exposes the issue
> differently."
> 

Anyway, after upgrading to Yakkety (Ubuntu 16.10), I found that the bug has disappeared/fixed/gone_in_a_place_where_good_bugs_do_bad_things . Running with the good ol' nvidia 340.98.

I have quite the opposite result, my issues began with the update to Yakkety. I'm using nvidia-340.98 with disabled compositor. My konsole sessions were crashing so fast (and always took all existing windows with them) that I needed to switch to qterminal for the time being.

(In reply to Daniel Eckl from comment #82)
> I have quite the opposite result, my issues began with the update to
> Yakkety. I'm using nvidia-340.98 with disabled compositor. My konsole
> sessions were crashing so fast (and always took all existing windows with
> them) that I needed to switch to qterminal for the time being.

Might this be a different bug? The problem here isn't actually konsole crashing, rather than konsole process running in the background consuming 100% of a cpu core, after being "exited" by the X button.

You are right, my issue does not match the topic, but crashes have been discussed here, too. I will reconsider and search for other bugs on this tracker. Thank you for pointing this out.

So, we have users who saw this bug with xenial and then the bug go away with yakkety, but there are also users (at least me) who did not see the bug with xenial and see it with yakkety. Then we have users on nvidia 361 before 18 see it, then see it disappear with .18 and reappear again with .28 (when possibly nvidia had never touched anything directly related to the issue in the driver).

This looks very much like an issue triggered by timings of events / races.

And it is very much possible that noveau cures it not because it has "better opengl" but because it is slower in some paths, significantly changing the timing of things.

Can it be a Qt issue.

I absolutely have this issue, too, using Kubuntu 16.10 Yakkety Yak and nvidia-340.98.

After I tried to reproduce my (supposedly unrelated) konsole crash issue I closed every konsole window. There was no 100% process running then, I checked that. Way later I noticed one cpu core was running at 100% and it turned out it was a konsole process.

Reported to the Qt bug tracker

https://bugreports.qt.io/browse/QTBUG-56766

This is very strange. I experienced this problem on Kubuntu 15.10 but then after upgrading to 16.04 it disappeared, but now after upgrading to 16.10 it came back! I would have to agree that this is some kind of race condition only getting triggered by a combination of different driver and library versions etc. This particular system is using the Nvidia legacy driver 340.98

I've tried:

OpenGL 2 and 3.
XRender
KWin
TWIN (trinity)
Compiz
Without any composite.
Without any window manager.

And the error is always produced.

As I see that no one is trying to solve this and other problems of stability with Plasma, I happened to Trinity and problem solved for me.

A reflection, offtopic.

After a few years kubuntu 14.04 was relatively stable, now it is without support and we have to use 16.04 very unstable, within 3 years, when it is stable we will again have to undergo another unstable version.

Have we gone crazy?

Same problem :
Opensuse Leap 42.1 
Kernel 4.9.0-4
Nvidia 340.101 patched for 4.9 kernel series + KDE 
KDE Frameworks 5.29.0
Qt 5.7.1

I found this workaroud : if konsole is executed under strace the problem doesn't occur. So, in KDE Menu Editor you can change "konsole" command into "strace konsole".

This had been gone for me for a long time with Plasma 5.8 on Linux Mint 18, with the Nvidia 384.90 driver.  However, at some point, the issue has returned.  This issue is therefore not just a 340 driver problem.  The only reason I noticed it was because I have a CPU temperature desktop widget loaded, and noticed it was a bit high.  Lo and behold, a rogue Konsole process was running and driving one of my CPU cores at 100%.

Thanks to antonio for the strace workaround.  I'll give that a go!

Unfortunately running things under strace just to get rid of some timing race is a bit expensive in terms of wasted resources. 

From the strace manual:
A traced process runs slowly.

This is because strace operates in a slightly violent manner: pausing the target process for each syscall so that the debugger can read state. This happens twice: when the syscall begins, and when it ends.

Incidentally, this is possibly the reason why strace is effective in working around the bug as it changes timings in rather strong way. 

So, it may be better to rely on nouveau (if possible) or on some other terminal emulator like the one from LxQt (if it is not possible to use the nouveau drivers) for the time being. Fortunately, the KDE Konsole seems to be the single application affected by this (timing?) issue, which makes a replacement possible (even if obviously undesirable).

I use stable KDE plasma 5.8.8 on my Kubuntu 16.04 and the issue is still reproducible. Today Konsole took full power of one of my core. I use NVIDIA 384.90 proprietary driver.

Does any of the developer know about this issue? It seems that nobody care of quite important bug. But, this is one of these bug that destroys your whole experience with the environment. Because, as a developer I use terminal constantly. I hope somebody will fix it soon.

Developers care, but are not able to debug problems with NVIDIA binary drivers.

Thank you for your response. Meanwhile I whip out my Kubuntu 16.04 distribution with stable Plasma and replace it with latest KDE Neon and the bug doesn't reproduce there. I also install Nvidia proprietary driver. So, the hardware configuration and driver is similar.

I would like to also add that the driver version on each distribution might be different. I also use the same Xorg.conf file.

However, I can not confirm that the problem is fixed, because in the past week I didn't use konsole much often. But, when I use it it didn't cause any CPU heavy usage.

Did you test this issue on Kubuntu 16.04 or you try only on specific distribution?

I am glad I receive feedback from KDE.

I forgot to add that currently I use 5.11.5. And on this version KDE posses less bugs.

Same Problem on two different machines using Linux Mint 18.3 and Kubuntu 16.04, both with NVIDIA drivers running.

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

I'm unable to reproduce this issue on current Konsole from git master.

Can you please test and confirm if this issue is still occurring, thanks.

I have not seen this happen for quite some time.
konsole-20.08.2

(In reply to Patrick Shanahan from comment #101)
> I have not seen this happen for quite some time.
> konsole-20.08.2

Thanks for the prompt response Patrick.

I'm going to resolve this bug, however if other users are still experiencing the issue please reopen with updated information where possible, thanks.

Reported:	2015-02-05 06:56 UTC by DMT

It's now 2020-11-05 and I believe the problem is fixed! yay!
I have not seen the issue occur for some time.
Close it; but let us try REALLY hard not to let a regression slip in some day in the future.

Thanks for getting it fixed.