Created attachment 298807 [details] full backtrace when attaching gdb to a hung gnome-screenshot process gnome-screenshot from gnome-utils-3.2.1, when run on a system with nvidia-drivers-290.10, fails to terminate and uses 100% of the CPU. To reproduce: 1. run gnome-screenshot 2. click "Cancel" or "OK" (doesn't matter which) 3. watch as gnome-screenshot refuses to terminate and uses 100% of the CPU Observations: * the bug is caused by nvidia-drivers (it does not occur on a system with intel graphics; it had also been confirmed on IRC by a user who is using nvidia-drivers-290.10 on sabayon). * the bug does not occur if gnome-screenshot is started from gdb or strace. * the bug does not occur if either __GL_SINGLE_THREADED or _GL_NO_DSO_FINALIZER env variables are set to 1. Hypotheses: * This is not a duplicate of bug #375615. First, vte-based applications (gnome-terminal etc.) are not affected. Second, setting __GL_SINGLE_THREADED=1 works around this bug, but had no effect on #375615. Attaching gdb to a hung gnome-screenshot process gives the following backtrace: (gdb) bt full #0 0x00007f83aba70c21 in _nv012tls () from /usr/lib64/opengl/nvidia/lib/libnvidia-tls.so.290.10 No symbol table info available. #1 0x00007f83acf94eb3 in ?? () from /usr/lib64/libGL.so.1 No symbol table info available. #2 0x00007f83acf72519 in ?? () from /usr/lib64/libGL.so.1 No symbol table info available. #3 0x00007f83b41ca53d in _dl_fini () at dl-fini.c:250 nmaps = 108 nloaded = <optimized out> i = <optimized out> l = 0x7f83b4374000 ns = 0 maps = 0x7fffb74bd7e0 maps_size = 864 do_audit = 0 __PRETTY_FUNCTION__ = "_dl_fini" #4 0x00007f83b1799651 in __run_exit_handlers (status=0, listp=0x7f83b1ae44c8, run_list_atexit=true) at exit.c:78 atfct = <optimized out> onfct = <optimized out> cxafct = <optimized out> f = <optimized out> #5 0x00007f83b17996d5 in __GI_exit (status=<optimized out>) at exit.c:100 No locals. #6 0x00007f83b1783394 in __libc_start_main (main=0x409570 <main>, argc=1, ubp_av=0x7fffb74bdcd8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffb74bdcc8) at libc-start.c:258 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -6879416193278554092, 4237796, 140736268590288, 0, 0, 6879259410784309268, 6881506396704067604}, mask_was_saved = 0}}, priv = {pad = { 0x0, 0x0, 0x40ef00, 0x7fffb74bdcd8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 4255488}}} not_first_call = <optimized out> #7 0x000000000040aa0d in _start () No symbol table info available. The backtrace for all threads ("thread apply all bt full") is attached.
>(In reply to comment #0) > * the bug does not occur if either __GL_SINGLE_THREADED or _GL_NO_DSO_FINALIZER > env variables are set to 1. Should be __GL_NO_DSO_FINALIZER, sorry for the typo.
Created attachment 298809 [details] emerge --info
Have you tried on a new created user account? For example, I remember to still suffer vte issue in my account of one of my machines, but not on fresh accounts (but I haven't had time to find the offending config file :S)
(In reply to comment #3) Using a newly created account did not help.
*** Bug 409247 has been marked as a duplicate of this bug. ***
OK, I had opened *** Bug 409247, which was just closed as a duplicated to this bug...but I'm not sure if true or not. I was able to reproduce these same behaviors, but.... resolved it, by switching opengl back to xorg-x11, instead of nvidia (which of course has issues) Can you confirm on this bug, this is also the case? i.e. my steps on bug 409247 Steps to Reproduce: 1.eselect opengl set nvidia 2./etc/init.d/xdm stop 3./etc/init.d/xdm start 4. Login (gdm) 5. Fire up gnome-terminal 6. exit gnome terminal 7. Examine system-monitor or top, and find (in my case 1 of 4) cpu's spiked at 100% (you'll notice the process is still running) 8. Kill PID, and process drops back down 9. eselect opengl set xorg-x11 10. Repeat steps 2 - 6 11. System back to normal Actual Results: 100% CPU, and process still running after exit.
I ask if it's really a duplicate, because you state: " This is not a duplicate of bug #375615. First, vte-based applications (gnome-terminal etc.) are not affected" Where as my issue, this happens with gnome-terminal, AND gnome-screenshot
(In reply to comment #7) > I ask if it's really a duplicate, because you state: > > " This is not a duplicate of bug #375615. First, vte-based applications > (gnome-terminal etc.) are not affected" > > > Where as my issue, this happens with gnome-terminal, AND gnome-screenshot If you run "__GL_SINGLE_THREADED=1 gnome-screenshot" (or "__GL_SINGLE_THREADED=1 vte2_90") from a terminal, does it run and exit correctly?
(In reply to comment #8) > (In reply to comment #7) > > I ask if it's really a duplicate, because you state: > > > > " This is not a duplicate of bug #375615. First, vte-based applications > > (gnome-terminal etc.) are not affected" > > > > > > Where as my issue, this happens with gnome-terminal, AND gnome-screenshot > > If you run "__GL_SINGLE_THREADED=1 gnome-screenshot" (or > "__GL_SINGLE_THREADED=1 vte2_90") from a terminal, does it run and exit > correctly? No, it does not. I re-enabled opengl for nvidia. Fired up an xterm, and from the xterm, ran both: _GL_SINGLE_THREADED=1 gnome-terminal and _GL_SINGLE_THREADED=1 gnome-screenshot Both did not exit properly, and I had the high CPU spike.
(In reply to comment #9) > No, it does not. > > I re-enabled opengl for nvidia. Fired up an xterm, and from the xterm, ran > both: > > _GL_SINGLE_THREADED=1 gnome-terminal > > and > _GL_SINGLE_THREADED=1 gnome-screenshot > > Both did not exit properly, and I had the high CPU spike. Then you are probably right, your bug is not a duplicate of this one.
A workaround has been added to newer NVIDIA drivers for the broke OpenGL headers that X.org and mesa uses which causes this problem. This is resolved for newer versions of NVIDIA drivers or with a newer X.org stack.