On FreeBSD r292778/amd64 the most recent version of stellarium 0.15.0_1 crashes, while an older version 0.14.1 from December 2015 ports works fine. There is also a bug report in LP in https://bugs.launchpad.net/stellarium/+bug/1608180 with more information;
@Matthias, If you can provide a log of the crash on startup and a backtrace of the core (as attachments that would be great
Logs and backtrace are in the upstream bug report (See Also) Thanks Matthias
I have built a memstick with 12-CURRENT (r303343) and installed into it the packages pkg, xorg, kde and stellarium (and all its ~800 dependencies) of a ports build of July 16 (r418627), stellarium is 0.14.3 at this level; the memstick works nice on my Dell Latitude E6330 and Acer C720; on the Dell stellarium works fine, on the Acer C720 it crashes with the known simptoms: it starts and when it will bring the GUI to full screen, it crashes.
Created attachment 173620 [details] log file from Dell E6330 (stellarium -d), does not crashed
Created attachment 173621 [details] log file from Acer C720 (stellarium -d), crashed
I've updated the same hardware Acer C720 to 12-CURRENT r306769; the crash remains;
Does the problem still occur after recent port update to version 0.15.1?
Problem still exists with this port. (stellarium-qt4 starts without problems. But only as root, cause of GLX.
(In reply to w.schwarzenfeld from comment #8) Root should not be required (in the case of GLX as well). Is your desktop user a member of ``video'' group?
There was no Video group. I create one. Started stellarium an it crashed: Using default graphics system specified at build time: raster ------------------------------------------------------- [ This is Stellarium 0.12.6 - http://www.stellarium.org ] [ Copyright (C) 2000-2013 Fabien Chereau et al ] ------------------------------------------------------- Writing log file to: "/home/ngorx/.stellarium/log.txt" File search paths: 0 . "/home/ngorx/.stellarium" 1 . "/usr/local/share/stellarium" Attempting to use an existing older config file. Config file is: "/home/ngorx/.stellarium/config.ini" X Error: BadValue (integer parameter out of range for operation) 2 Extension: 153 (Uknown extension) Minor opcode: 3 (Unknown request) Resource id: 0x0 QGLTempContext: Unable to create GL context. Going to initialize the OpenGL 2 renderer X Error: BadValue (integer parameter out of range for operation) 2 Extension: 153 (Uknown extension) Minor opcode: 3 (Unknown request) Resource id: 0x0 QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. GL vendor is "" GL renderer is "" X Error: BadValue (integer parameter out of range for operation) 2 Extension: 153 (Uknown extension) Minor opcode: 3 (Unknown request) Resource id: 0x0 QGLTempContext: Unable to create GL context. Failed to add default projection vertex shader: "" Failed to compile vertex shader of builtin shader " plainShader " : "" StelQGL2Renderer::init failed to load plain shader Failed to initialize the OpenGL 2 renderer, falling back to the OpenGL 1 renderer ==> this is the GLX_Error X Error: BadValue (integer parameter out of range for operation) 2 Extension: 153 (Uknown extension) Minor opcode: 3 (Unknown request) Resource id: 0x0 QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. GL vendor is "" GL renderer is "" QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. [2]+ Segmentation fault (core dumped) stellarium With root all ok.
The "GLX-Error" is a bug in nvidia-driver-304 (see Bug 216574 ).
But it seems the qt5 problem is an other problem.
I have a few remarks on this issue 1) I own a bunch of laptops Dell E6330 and netbooks Acer C720, they all run the same binary software (kernel and ports compiled on my poudriere oven, a Dell PowerEdge R210), all 12-CURRENT r314251 and packages compiled from ports r435425 (March 4, 2017). On the Dell 6330 the stellarium 0.15.1 runs fine, while the same binary crashes on all Acer C720, always at the same place (when bringing up the GUI after splash screen). 2) The same binary system+port is installed at work in Vbox on a Win7 host, using the same Xorg + vboxvideo driver. As well here stellarium works fine. 3) This let me think, that the issue is related to the video stack in the C720 (Xorg with vesa driver); the Dell 6330 uses same Xorg with intel driver; 4) With the recent update of all my systems to r314251+r435425 another application with heavy GUI, the ports/games//flightgear, shows now the same problem: works fine on Dell 6330, crashes on Acer C720 when bringing up the GUI after splash;
I've updated one of the Acer C720 to the most recent graphic work kernel for FreeBSD from https://github.com/freebsd/freebsd-base-graphics which does allow to use the video-intel driver for Xorg. stellarium still crashed with the same symptoms while getting the GUI up, until I realized that the user must be in the group 'video' to have access to the files below /dev/dri: crw-rw---- 1 root video 0x6c 9 Apr. 12:57 card0 crw-rw---- 1 root video 0x6b 9 Apr. 12:57 controlD64 Adding the user to the group 'video' makes it finally work fine (also flightgear works too). On the other C720 system I still have to use the vesa driver for Xorg and there are no files or dir /dev/dri. This would explain why stellarium crashes there, but would not explain how it worked this way in the past.
So... Does it mean this bug can be closed now?
additional information: stellarium works even on a normal (compiled from SVN) CURRENT kernel when: a) the kmod i915kms.ko and its dependencies are loaded (which must be done in the C720 *after* boot due to conflicts with the kmod cyapa.ko) b) the Xorg server is using the video-intel driver from ports/x11-drivers/xf86-video-intel c) the user is in group 'video' it does not work definitely with Xorg+vesa; Re/ your question if we could close this issue: we (FreeBSD) or upstream should make this clear and take care that it does not just crashes with no further information about unsufficient environment; it took months to get this to know;
Seems solved with 0.16.1.
Hey Matthias, can you try the latest version (0.19.0, already in the ports) and check if the problem still exhibits itself?
I run 1.18.2 which works fine now. We can close this thread.