stellarium crashes on 9.0-CURRENT
in [Ports]
|
Prev: pecl-imagick -> Segmentation fault: 11 (core dumped)on php -i under freebsd 7.3
Next: Who to bug to commit some ports?
From: Rainer Hurling on 22 Jun 2010 07:56 For some weeks now I am not able to start astro/stellarium (versions 10.3 and 10.5) any more. Immediately after starting I only get a core dump, nothing else. It seems like this behaviour appeared after the latest update of KDE / QT. I am running recent 9.0-CURRENT (amd64) with x11/nvidia-driver. Other OpenGL programs like astro/celestia and astro/openunivers work like a charm. Looking at the core dump with gdb gives me the following output (btw. it seems to be difficult to build stellarium with debugging symbols, any hints?): ---------------------------------------------------------------- (gdb) core stellarium.core warning: exec file is newer than core file. Core was generated by `stellarium'. Program terminated with signal 11, Segmentation fault. Symbols already loaded for /usr/local/lib/qt4/libQtOpenGL.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtScript.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtGui.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtSql.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtNetwork.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtCore.so.4 Symbols already loaded for /usr/local/lib/libGLU.so.1 Symbols already loaded for /usr/local/lib/libGL.so.1 Symbols already loaded for /usr/local/lib/libSM.so.6 Symbols already loaded for /usr/local/lib/libICE.so.6 Symbols already loaded for /usr/local/lib/libX11.so.6 Symbols already loaded for /usr/local/lib/libXext.so.6 Symbols already loaded for /usr/local/lib/libiconv.so.3 Symbols already loaded for /usr/local/lib/libintl.so.9 Symbols already loaded for /lib/libz.so.6 Symbols already loaded for /usr/lib/libstdc++.so.6 Symbols already loaded for /lib/libm.so.5 Symbols already loaded for /lib/libgcc_s.so.1 Symbols already loaded for /lib/libc.so.7 Symbols already loaded for /usr/local/lib/libfreetype.so.9 Symbols already loaded for /usr/local/lib/libXrender.so.1 Symbols already loaded for /usr/local/lib/libfontconfig.so.1 Symbols already loaded for /lib/libthr.so.3 Symbols already loaded for /usr/local/lib/libgthread-2.0.so.0 Symbols already loaded for /usr/local/lib/libglib-2.0.so.0 Symbols already loaded for /usr/local/lib/libpng.so.6 Symbols already loaded for /usr/local/lib/libnvidia-tls.so.1 Symbols already loaded for /usr/local/lib/libGLcore.so.1 Symbols already loaded for /usr/local/lib/libxcb.so.2 Symbols already loaded for /usr/local/lib/libXau.so.6 Symbols already loaded for /usr/local/lib/libXdmcp.so.6 Symbols already loaded for /usr/local/lib/libpthread-stubs.so.0 Symbols already loaded for /usr/lib/librpcsvc.so.5 Symbols already loaded for /usr/local/lib/libexpat.so.6 Symbols already loaded for /usr/local/lib/libicui18n.so.38 Symbols already loaded for /usr/local/lib/libpcre.so.0 Symbols already loaded for /usr/local/lib/libicuuc.so.38 Symbols already loaded for /usr/local/lib/libicudata.so.38 Symbols already loaded for /libexec/ld-elf.so.1 #0 0x000000004271b143 in glXCreateWindow () from /usr/local/lib/libGL.so.1 ---------------------------------------------------------------- This looks like a problem with OpenGL (QT / NVidia?). I have no clue what to do next ... Any help is really appreciated. Thanks in advance, Rainer Hurling _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Rainer Hurling on 10 Jul 2010 16:40 On 10.07.2010 22:19 (UTC+1), Henry Hu wrote: > Hello, Hello Henry, > I'm using FreeBSD 8.0-STABLE, and I'm suffering from the problem. > After days of debugging, I still cannot make out the problem. > However, there is a solution to me: run with __GL_SINGLE_THREADED=1 > e.g. run: > env __GL_SINGLE_THREADED=1 stellarium > It was segfaulting before, and now it works! thank you for your answer. I can confirm that stellarium with this variable set works on 9.0-CURRENT too. > My stacktrace: > [Switching to LWP 100190] > 0x29f44260 in pthread_mutexattr_setkind_np () from /lib/libthr.so.3 > (gdb) where > #0 0x29f44260 in pthread_mutexattr_setkind_np () from /lib/libthr.so.3 > #1 0x299d0ba3 in glXChooseVisual () from /usr/local/lib/libGL.so.1 > #2 0x00000002 in ?? () > #3 0x00000000 in ?? () > #4 0x29e284fd in atoi () from /lib/libc.so.7 > #5 0x00000000 in ?? () > #6 0x28615d70 in ?? () > #7 0x2ac1a890 in ?? () from /usr/local/lib/libGLcore.so.1 > #8 0x00000003 in ?? () > #9 0xbfbfe4a8 in ?? () > #10 0xbfbfdf18 in ?? () > #11 0x2adcf2c5 in _nv012glcore () from /usr/local/lib/libGLcore.so.1 > #12 0x28615d70 in ?? () > #13 0xbfbfe4a8 in ?? () > #14 0xbfbfdf18 in ?? () > #15 0x299b76db in glXChooseVisual () from /usr/local/lib/libGL.so.1 > #16 0x29a055dc in ?? () from /usr/local/lib/libGL.so.1 > (gdb) > > Generally, it seems like that the program crashed before main. > > According to where I found the environment variable(in NVIDIA > Accelerated Linux Driver Set README and Installation Guide): > [quote] > > Q. OpenGL applications crash and print out the following warning: > > > WARNING: Your system is running with a buggy dynamic loader. > This may cause crashes in certain applications. If you > experience crashes you can try setting the environment > variable __GL_SINGLE_THREADED to 1. For more information > please consult the FREQUENTLY ASKED QUESTIONS section in > the file /usr/share/doc/NVIDIA_GLX-1.0/README.txt. > > > > A. The dynamic loader on your system has a bug which will cause applications > > linked with pthreads, and that dlopen() libGL multiple times, to crash. > This bug is present in older versions of the dynamic loader. Distributions > that shipped with this loader include but are not limited to Red Hat Linux > 6.2 and Mandrake Linux 7.1. Version 2.2 and later of the dynamic loader are > known to work properly. If the crashing application is single threaded then > setting the environment variable '__GL_SINGLE_THREADED' to "1" will prevent > the crash. In the bash shell you would enter: > > % export __GL_SINGLE_THREADED=1 > > and in csh and derivatives use: > > % setenv __GL_SINGLE_THREADED 1 > > Previous releases of the NVIDIA Accelerated Linux Driver Set attempted to > work around this problem. Unfortunately the workaround caused problems with > other applications and was removed after version 1.0-1541. > > [/quote] > I found that stellarium is linked with pthreads, and according to my debugging, > this problem may be related to dlopen. > However, I tried to write a program which uses pthread and dlopens > libGL multiple times, > but it did not crash. > Is this a problem related to our dynamic loader? Or is this a problem > of the nvidia drivers? Sorry, but I have no knowledge about the actual loader (did it change in the last month?). > I remember that once stellarium was running successfully with nvidia's > driver. So something must > have changed. Yes, I was running previous versions (before 10.0.2) of stellarium with nvidia-driver. Your workaround helps so far, but of course it would be nice to have a general solution. As I mentioned in my initial mail, other OpenGL programs like astro/celestia etc. work like a charm. Many thanks again, Rainer _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Henry Hu on 10 Jul 2010 16:19
Hello, I'm using FreeBSD 8.0-STABLE, and I'm suffering from the problem. After days of debugging, I still cannot make out the problem. However, there is a solution to me: run with __GL_SINGLE_THREADED=1 e.g. run: env __GL_SINGLE_THREADED=1 stellarium It was segfaulting before, and now it works! My stacktrace: [Switching to LWP 100190] 0x29f44260 in pthread_mutexattr_setkind_np () from /lib/libthr.so.3 (gdb) where #0 0x29f44260 in pthread_mutexattr_setkind_np () from /lib/libthr.so.3 #1 0x299d0ba3 in glXChooseVisual () from /usr/local/lib/libGL.so.1 #2 0x00000002 in ?? () #3 0x00000000 in ?? () #4 0x29e284fd in atoi () from /lib/libc.so.7 #5 0x00000000 in ?? () #6 0x28615d70 in ?? () #7 0x2ac1a890 in ?? () from /usr/local/lib/libGLcore.so.1 #8 0x00000003 in ?? () #9 0xbfbfe4a8 in ?? () #10 0xbfbfdf18 in ?? () #11 0x2adcf2c5 in _nv012glcore () from /usr/local/lib/libGLcore.so.1 #12 0x28615d70 in ?? () #13 0xbfbfe4a8 in ?? () #14 0xbfbfdf18 in ?? () #15 0x299b76db in glXChooseVisual () from /usr/local/lib/libGL.so.1 #16 0x29a055dc in ?? () from /usr/local/lib/libGL.so.1 (gdb) Generally, it seems like that the program crashed before main. According to where I found the environment variable(in NVIDIA Accelerated Linux Driver Set README and Installation Guide): [quote] Q. OpenGL applications crash and print out the following warning: WARNING: Your system is running with a buggy dynamic loader. This may cause crashes in certain applications. If you experience crashes you can try setting the environment variable __GL_SINGLE_THREADED to 1. For more information please consult the FREQUENTLY ASKED QUESTIONS section in the file /usr/share/doc/NVIDIA_GLX-1.0/README.txt. A. The dynamic loader on your system has a bug which will cause applications linked with pthreads, and that dlopen() libGL multiple times, to crash. This bug is present in older versions of the dynamic loader. Distributions that shipped with this loader include but are not limited to Red Hat Linux 6.2 and Mandrake Linux 7.1. Version 2.2 and later of the dynamic loader are known to work properly. If the crashing application is single threaded then setting the environment variable '__GL_SINGLE_THREADED' to "1" will prevent the crash. In the bash shell you would enter: % export __GL_SINGLE_THREADED=1 and in csh and derivatives use: % setenv __GL_SINGLE_THREADED 1 Previous releases of the NVIDIA Accelerated Linux Driver Set attempted to work around this problem. Unfortunately the workaround caused problems with other applications and was removed after version 1.0-1541. [/quote] I found that stellarium is linked with pthreads, and according to my debugging, this problem may be related to dlopen. However, I tried to write a program which uses pthread and dlopens libGL multiple times, but it did not crash. Is this a problem related to our dynamic loader? Or is this a problem of the nvidia drivers? I remember that once stellarium was running successfully with nvidia's driver. So something must have changed. -- Cheers, Henry _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |