stellarium assert failure: nv10_state_fb.c:50: get_rt_format: Assertion `0' failed.

[John Harrington]

Stellarium crashes a few seconds after displaying the startup screen with this message in terminal:

nv10_state_fb.c:50: get_rt_format: Assertion `0' failed.

I have an nvidia GeForce4 MX 4000 video card, and have installed libgl1-mesa-dri and libgl1-mesa-dri-experimental, version 9.0-0ubuntu1.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: stellarium 0.11.3-1
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic i686
ApportVersion: 2.6.1-0ubuntu6
Architecture: i386
Date: Wed Nov 14 22:52:36 2012
InstallationDate: Installed on 2012-04-05 (224 days ago)
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: stellarium
UpgradeStatus: Upgraded to quantal on 2012-10-20 (25 days ago)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tucker Sunder (tuckersunder)]

This doesn't only affect the stellarium package; it also affects flightgear.

[Rebecca Palmer (rebecca-palmer)]

That message means "invalid/unsupported buffer format" ( http://sources.debian.net/src/mesa/10.3.2-1/src/mesa/drivers/dri/nouveau/nv10_state_fb.c ), and as it appears to refer to an internal nouveau buffer rather than a passed-in texture, I suspect this is actually a mesa/nouveau bug.

As I do not have the hardware to test this myself, please do (in a terminal):

$ sudo apt-get install libgl1-mesa-dri-dbg gdb
$ gdb --args fgfs
[or gdb --args stellarium, whichever is easier to reproduce the crash in]
(gdb) set pagination 0
(gdb) run
[wait for crash]
(gdb) thread apply all bt full

and post the ouput here.

[John Harrington (j-fharrington)]

I have removed Ubuntu from this machine, so can't test under Ubuntu. I am now running Sparky Linux (Debian testing). Stellarium still crashes after displaying the startup screen, but I'm now getting this error message:

stellarium: ../../../../../../../src/mesa/drivers/dri/nouveau/nv10_render.c:104: get_hw_format: Assertion `0' failed.

For whatever it's worth, I did the routine you described. The Stellarium startup screen appeared but didn't disappear. I had to kill the process. Here's the output:

(gdb) run
Starting program: /usr/local/bin/stellarium
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Using default graphics system specified at build time: raster
[New Thread 0xb43deb40 (LWP 1146)]
 -------------------------------------------------------
[ This is Stellarium 0.12.4 - http://www.stellarium.org ]
[ Copyright (C) 2000-2013 Fabien Chereau et al ]
 -------------------------------------------------------
Writing log file to: "/home/<user>/.stellarium/log.txt"
File search paths:
  0 . "/home/<user>/.stellarium"
  1 . "/usr/local/share/stellarium"
Attempting to use an existing older config file.
Config file is: "/home/<user>/.stellarium/config.ini"
Going to initialize the OpenGL 2 renderer
OpenGL supported version: "1.2 Mesa 10.3.2"
Qt GL paint engine is: "OpenGL"
[New Thread 0xb1eacb40 (LWP 1157)]
StelQGL2Renderer::init : Failed because Qt paint engine is not OpenGL2
If paint engine is OpenGL3 or higher, this code needs to be updated
Failed to initialize the OpenGL 2 renderer, falling back to the OpenGL 1 renderer
[Thread 0xb1eacb40 (LWP 1157) exited]
OpenGL supported version: "1.2 Mesa 10.3.2"
Qt GL paint engine is: "OpenGL"
[New Thread 0xb1eacb40 (LWP 1158)]
GL vendor is "Nouveau"
GL renderer is "Mesa DRI nv18 x86/MMX+/3DNow!+/SSE2"
Cache directory is: "/home/harrington/.cache/stellarium/stellarium"
Sky language is "en_US"
Application language is "en_US"
Loading Solar System data ...
Loaded 75 / 75 planet orbits from "/home/<user>/.stellarium/data/ssystem.ini"
Loading star data ...
"Loading "/usr/local/share/stellarium/stars/default/stars_0_0v0_3.cat": 0_0v0_2; 4963"
"Loading "/usr/local/share/stellarium/stars/default/stars_1_0v0_3.cat": 1_0v0_2; 21598"
"Loading "/usr/local/share/stellarium/stars/default/stars_2_0v0_3.cat": 2_0v0_2; 150090"
"Loading "/usr/local/share/stellarium/stars/default/stars_3_1v0_2.cat": 3_1v0_1; 423540"
Finished loading star catalogue data, max_geodesic_level: 3
navigation/preset_sky_time is a double - treating as jday: 2.45151e+06
Loaded 10051 NGC records
Loading NGC name data ...
Loaded 412 / 412 NGC name records successfully
Loading star names from "/usr/local/share/stellarium/skycultures/western/star_names.fab"
Loaded 236 / 236 common star names
Loading star names from "/usr/local/share/stellarium/stars/default/name.fab"
Loaded 4359 / 4359 scientific star names
Loading variable stars from "/usr/local/share/stellarium/stars/default/gcvs_hip_part.dat"
Loaded 6886 / 6886 variable stars
Loaded 88 / 88 constellation records successfully for culture "western"
Lo...

[Rebecca Palmer (rebecca-palmer)]

> stellarium: ../../../../../../../src/mesa/drivers/dri/nouveau/nv10_render.c:104: get_hw_format: Assertion `0' failed.
That also appears to mean "invalid format", so is probably the same bug.

> For whatever it's worth, I did the routine you described. The Stellarium startup screen appeared but didn't disappear.
That's expected when something crashes under a debugger: please switch back to the debugger window (Alt+Tab), type "thread apply all bt full" and post the output. (You can then close the debugger and program with "quit".)

[John Harrington (j-fharrington)]

Thanks for helping me with this. Here's the output:

stellarium: ../../../../../../../src/mesa/drivers/dri/nouveau/nv10_render.c:104: get_hw_format: Assertion `0' failed.

Program received signal SIGABRT, Aborted.
0xb7fdcd30 in __kernel_vsyscall ()
(gdb) thread apply all bt full

Thread 5 (Thread 0xafe90b40 (LWP 32108)):
#0 0xb7fdcd30 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb661fc4b in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
No locals.
#2 0xb695d98c in __pthread_cond_wait (cond=0xb7ea38f0, mutex=0xb7ea38d8) at forward.c:149
        __p = <optimized out>
#3 0xb7d8724f in ?? () from /usr/lib/i386-linux-gnu/libQtScript.so.4
No symbol table info available.
#4 0xb7d8728c in ?? () from /usr/lib/i386-linux-gnu/libQtScript.so.4
No symbol table info available.
#5 0xb661befb in start_thread (arg=0xafe90b40) at pthread_create.c:309
        __res = <optimized out>
        pd = 0xafe90b40
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1235034112, -1343681728, 4001536, -1343683608, 275888271, 17451196}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#6 0xb6950dfe in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
No locals.

Thread 4 (Thread 0xb1eacb40 (LWP 32107)):
#0 0xb7fdcd30 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb69465bb in poll () at ../sysdeps/unix/syscall-template.S:81
No locals.
#2 0xb64e40b0 in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3 0xb64d5054 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4 0xb64d5196 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5 0xb6e4d014 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
No symbol table info available.
#6 0xb6e1961f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
No symbol table info available.
#7 0xb6e199ae in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
No symbol table info available.
#8 0xb6cfe7eb in QThread::exec() () from /usr/lib/i386-linux-gnu/libQtCore.so.4
No symbol table info available.
#9 0xb6cfe9c8 in QThread::run() () from /usr/lib/i386-linux-gnu/libQtCore.so.4
No symbol table info available.
#10 0xb6d013ce in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
No symbol table info available.
#11 0xb661befb in start_thread (arg=0xb1eacb40) at pthread_create.c:309
        __res = <optimized out>
        pd = 0xb1eacb40
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1235034112, -1310012608, 4001536, -1310014488, 401717427, 17451196}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev...

[Rebecca Palmer (rebecca-palmer)]

(Sorry about the repeated questions: that's the nature of debugging a problem that only happens on hardware I don't have.)

That looks like either a bad GLcontext (at the error location it is only looking at this internal structure, not the objects to be drawn), or an attempt to use VBO (an OpenGL 1.5 feature) on an OpenGL 1.2 card.

Can you try this, preferably in a terminal with unlimited scrollback (Edit > Profile Preferences > Scrolling) as there may be a lot of output:
$ sudo apt-get install libqt4-dbg mesa-utils
$ glxinfo
$ gdb --args stellarium
(gdb) run
[wait for crash, Alt+Tab back to terminal]
[all this is at the (gdb) prompt, writing it without prompts so you can cut and paste it]
set pagination 0
thread apply all bt full
frame 9
print *ctx
print *nctx
frame 10
print *vbo
print *exec

[John Harrington (j-fharrington)]

See attached file for glxinfo output

[John Harrington (j-fharrington)]

See attached file for (gdb) run and thread apply all bt full output

[John Harrington (j-fharrington)]

See attached file for (gdb) frame 9, print *ctx, and print *nctx output

[John Harrington (j-fharrington)]

See attached file for (gdb) frame 10, print *vbo, and print *exec output

[Rebecca Palmer (rebecca-palmer)]

The error occurs because nv10 (the driver used for this card) declares VBO support (extension GL_ARB_vertex_buffer_object) but only supports VBOs of int8, int16 and float (not double) types, and the application is trying to draw data of type double. Given that the double type is part of the OpenGL spec, that would appear to be a bug in mesa, not the application.

The easy fix would be "don't declare VBO support on those cards", but that would slow down many other applications, and break any that require this feature.

An alternative would be a software fallback that reads back the VBO data and draws it as either a client-side array or individual primitives (which would probably be even slower, but only applications that actually use doubles would take the penalty), but that might be more work than is reasonable to do for little benefit: stellarium and other QtOpenGL applications will lose OpenGL 1 support in the upcoming Qt 5 transition anyway, and flightgear would probably be unusably slow on such old hardware even if it didn't crash.

As an immediate workaround, you can use software rendering with
LIBGL_ALWAYS_SOFTWARE=1 stellarium
(perhaps the error message should suggest that?), but expect that to be slow.

I will report this upstream.

[Rebecca Palmer (rebecca-palmer)]

Sorry, upstream explicitly don't want bug reports for cards older than nv30 (yours is nv18, current is ~nv120): http://nouveau.freedesktop.org/wiki/MesaDrivers/

Changing the error message (at http://sources.debian.net/src/mesa/10.3.2-1/src/mesa/drivers/dri/nouveau/nv10_render.c/#L104 ) to something more useful, e.g.

- assert(0);
+ assert(0 && "This application requires GLdouble vertex buffers, which your graphics card does not support. Try software rendering (LIBGL_ALWAYS_SOFTWARE=1 <application>).");

is probably about all that is reasonable to do as a Debian/Ubuntu patch.

[John Harrington (j-fharrington)]

Thanks for looking into this for me.

[sidlwebb (sidlwebb)]

i can;t do anything with this os!

[Rebecca Palmer (rebecca-palmer)]

Assigning a bug to yourself means intending to fix it, which given that you "can;t do anything" was probably not what you meant.

If your system does not work, please file a new bug stating exactly what is wrong: https://help.ubuntu.com/community/ReportingBugs

If you are looking for general help with using Ubuntu, please use http://www.ubuntuforums.org/ or http://askubuntu.com/

[Rebecca Palmer (rebecca-palmer)]

As nobody has been able to test this in flightgear, assuming it's the same really-in-mesa problem. (It's also likely that this hardware wouldn't run flightgear at a usable speed anyway.)

[penalvch (penalvch)]

John Harrington, thank you for reporting this and helping make Ubuntu better.

As per https://wiki.ubuntu.com/Releases, Ubuntu 12.10 reached EOL on May 16, 2014.

Is this reproducible with a supported release?

[Launchpad Janitor (janitor)]

[Expired for mesa (Ubuntu) because there has been no activity for 60 days.]