Proper fix for "blocked signals" issue in 180.xx.

[hdas]

This blocked signals issue was severe in 180.35 and seems to have been only partially addressed in 180.37. To elaborate, it is a issue with only few gtk applications segfaulting. And it seems to be more problematic in Gentoo.The good part with 180.37 was that binary firefox trunk (minefield, 3.6a1pre) has started working again - it did not work in Gentoo for any 180.xx till 180.35, but it was fine in 177.xx. The bad part with >=180.35 is that gnome-bluetooth segfaults. It is a regression, since gnome-bluetooth works fine in 180.29 (but not minefield binaries). For now, the workaround is to start these applications in Gentoo with LD_PRELOAD=/usr/lib/opengl/xorg-x11/lib/libGL.so (verifying that the problem is indeed with nvidia's libgl.so, as also seen in the system logs.) Strangely, these issues are not present in Ubuntu (except for 180.35 which was totally weird).

[zander]

Please see http://www.nvnews.net/vbulletin/showthread.php?t=46678.

[hdas]

Thanks for the attention . I thought it was redundant to post a formal bug report, since it is a well known problem. Quite some time has passed and even in 185.19, it is not fixed . I am attaching the bug report for this driver (after I ran 'bluetooth-applet' and it segfaulted).

Meanwhile, apart from dmesg, valgrind and gdb etc also indicate the issue with nvidia's gl libs. Here is the valgrind output (valgrind --leak-check=full bluetooth-applet):

==5572== Memcheck, a memory error detector.
==5572== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==5572== Using LibVEX rev 1884, a library for dynamic binary translation.
==5572== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==5572== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==5572== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==5572== For more details, rerun with: -v
==5572==
==5572== Invalid read of size 4
==5572== at 0x8705EBE: (within /usr/lib64/opengl/nvidia/lib/libGL.so.185.19)
==5572== by 0x316DDF: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E8F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E7F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E0F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E2F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E3F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316EBF: (within /usr/bin/bluetooth-applet)
==5572== by 0x316ECF: (within /usr/bin/bluetooth-applet)
==5572== by 0x316EDF: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E4F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E5F: (within /usr/bin/bluetooth-applet)
==5572== Address 0x2102b0 is not stack'd, malloc'd or (recently) free'd
==5572==
==5572== Process terminating with default action of signal 11 (SIGSEGV)
==5572== Access not within mapped region at address 0x2102B0
==5572== at 0x8705EBE: (within /usr/lib64/opengl/nvidia/lib/libGL.so.185.19)
==5572== by 0x316DDF: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E8F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E7F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E0F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E2F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E3F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316EBF: (within /usr/bin/bluetooth-applet)
==5572== by 0x316ECF: (within /usr/bin/bluetooth-applet)
==5572== by 0x316EDF: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E4F: (within /usr/bin/bluetooth-applet)
==5572== by 0x316E5F: (within /usr/bin/bluetooth-applet)
==5572== If you believe this happened as a result of a stack overflow in your
==5572== program's main thread (unlikely but possible), you can try to increase
==5572== the size of the main thread stack using the --main-stacksize= flag.
==5572== The main thread stack size used in this run was 8388608.
==5572==
==5572== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 1)
==5572== malloc/free: in use at exit: 179,733 bytes in 27 blocks.
==5572== malloc/free: 105 allocs, 78 frees, 186,682 bytes allocated.
==5572== For counts of detected errors, rerun with: -v
==5572== searching for pointers to 27 not-freed blocks.
==5572== checked 5,411,648 bytes.
==5572==
==5572==
==5572== 984 (248 direct, 736 indirect) bytes in 1 blocks are definitely lost in loss record 26 of 27
==5572== at 0x4C22AD4: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==5572== by 0xC96A000: (within /usr/lib64/opengl/nvidia/lib/libGLcore.so.185.19)
==5572== by 0x7FEFFF947: ???
==5572==
==5572== LEAK SUMMARY:
==5572== definitely lost: 248 bytes in 1 blocks.
==5572== indirectly lost: 736 bytes in 19 blocks.
==5572== possibly lost: 0 bytes in 0 blocks.
==5572== still reachable: 178,749 bytes in 7 blocks.
==5572== suppressed: 0 bytes in 0 blocks.
==5572== Reachable blocks (those to which a pointer was found) are not shown.
==5572== To see them, rerun with: --leak-check=full --show-reachable=yes
Segmentation fault

[hdas]

For now, happy with USE=-glitz (on Gentoo) . (Details here.) [SOLVED]