strange messages on the console in ubuntu

[Beowulf]

Hi,
I'm trying to run vegastrike (yesterday's subversion head) on ubuntu 7.04 and I'm getting lots of

Code: Select all

Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org

on the console. I'm not even sure if this is a bug in vegastrike or in mesa. Hardware acceleration seems to be used:

Code: Select all

# glxinfo |grep -i direct
direct rendering: Yes

The graphics card is a

Code: Select all

# lspci|grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

Any thoughts?

[loki1950]

Think i remember something like that with an other INTEL GPU the driver does not support hardware compression i forget the workaround if there was one.

Edit:was browsing the fedora forum and this showed up the driver mentioned in that thread may be what you need http://forums.fedoraforum.org/showthread.php?t=157189

Enjoy the Choice

[hellcatv]

the function not supported error is printed out by mesa not by vega strike---
we'd be very interested in which function call brought out this error...you could build mesa in debug and break on that error in the mesa .so file then do a backtrace and see which function we called that mesa doesn't support--if it wasn't important we could design a workaround that didn't use it

[Beowulf]

the function not supported error is printed out by mesa not by vega strike---
we'd be very interested in which function call brought out this error...you could build mesa in debug and break on that error in the mesa .so file then do a backtrace and see which function we called that mesa doesn't support--if it wasn't important we could design a workaround that didn't use it

How do I do that? Install libgl1-mesa-..., set LD_LIBRARY_PATH to /usr/lib/debug/usr/lib and then what?

[Beowulf]

Think i remember something like that with an other INTEL GPU the driver does not support hardware compression i forget the workaround if there was one.

Edit:was browsing the fedora forum and this showed up the driver mentioned in that thread may be what you need http://forums.fedoraforum.org/showthread.php?t=157189

Enjoy the Choice

I switched to this driver but it didn't change anything. I noticed another error message on the console though that appears when I have another ship in front of me:

Code: Select all

[driAllocateTexture:636] unable to allocate texture

Also the game gets unplayably slow as soon as I have another ship in front of me.
EDIT: actually I'm not sure if this was a different driver I tried. I didn't download the git version from this website but used the package that comes with ubuntu. I'll take a look at it later today or tomorrow, maybe I can build packages for the versions on this website...

[ace123]

As to doing what hellcatv suggested, I describe how to use GDB in this way here:
http://vegastrike.sourceforge.net/forum ... 9108#89108

I'm making the assumption that Mesa uses printf for its errors... if you are unable to get it to break inside of libGL we will have to find a different way of debugging this.

[Beowulf]

As to doing what hellcatv suggested, I describe how to use GDB in this way here:
http://vegastrike.sourceforge.net/forum ... 9108#89108

I'm making the assumption that Mesa uses printf for its errors... if you are unable to get it to break inside of libGL we will have to find a different way of debugging this.

Alright, the gdb part works, but I cannot get it to use the debugging library. I specified

Code: Select all

LD_LIBRARY_PATH=/usr/lib/debug/usr/lib

but vegastrike still uses /usr/lib/dri/i915_dri.so instead of /usr/lib/debug/usr/lib/dri/i915_dri.so
I also tried to run it the following way without success:

Code: Select all

/lib/ld-linux.so.2 --library-path /usr/lib/debug/usr/lib:/usr/lib:/lib /usr/bin/gdb ../../vegastrike-svn/vegastrike

[ace123]

I recommend using LD_PRELOAD.

export LD_PRELOAD=/usr/lib/debug/usr/lib/libsomething.so

If LD_PRELOAD causes an error then you have an issue with the library you compiled or else you specified the wrong path.

Also, you can use the "ldd" command on vegastrike to see the full paths to all the .so library files it loads.

Have you gotten the break to work without a debugging library? It should hopefully at least be able to see what part of vegastrike is calling the library at the time of the error.

[Beowulf]

I recommend using LD_PRELOAD.

export LD_PRELOAD=/usr/lib/debug/usr/lib/libsomething.so

If LD_PRELOAD causes an error then you have an issue with the library you compiled or else you specified the wrong path.

Also, you can use the "ldd" command on vegastrike to see the full paths to all the .so library files it loads.

Have you gotten the break to work without a debugging library? It should hopefully at least be able to see what part of vegastrike is calling the library at the time of the error.

I tried to use LD_PRELOAD, it resulted in a segfault. I compiled debugging information into the vegastrike but gdb's output doesn't appear useful to me:

Code: Select all

(gdb) cont
Continuing.
Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org

Breakpoint 2, 0xb78a95f6 in fprintf () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt full
#0  0xb78a95f6 in fprintf () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#1  0xb2a01900 in _mesa_problem () from /usr/lib/dri/i915_dri.so
No symbol table info available.
#2  0xb29d4b6a in ?? () from /usr/lib/dri/i915_dri.so
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.
(gdb) bt
#0  0xb78a95f6 in fprintf () from /lib/tls/i686/cmov/libc.so.6
#1  0xb2a01900 in _mesa_problem () from /usr/lib/dri/i915_dri.so
#2  0xb29d4b6a in ?? () from /usr/lib/dri/i915_dri.so
#3  0x00000000 in ?? ()

[ace123]

Two possibilities... I'll tell you how to figure out.

One thing might be that it is actually in a different thread. You can find out by doing "info threads"

You should see thread 1 as having an asterisk and inside of fprintf, like this.

Code: Select all

  3 Thread 1091017024 (LWP 8941)  0x00002b00dcba4bd8 in __lll_mutex_lock_wait
    () from /lib/libpthread.so.0
  2 Thread 1082149184 (LWP 8940)  0x00002b00dce7b037 in ioctl ()
   from /lib/libc.so.6
* 1 Thread 47282749079760 (LWP 8939)  0x00002b00dcba5881 in fprintf ()

If the asterisk and fprintf is somewhere else (maybe thread 2 or 3), then you need to go to thread 1, which you can do by typing in gdb:

Code: Select all

thread 1
bt full

If the asterisk is in fact in thread 1, then the lack of debugging symbols is confusing GDB, but this is still fine with us.

Since the program is not crashing, but is only at a breakpoint, there is a solution for this. Until "bt" gives you meaningful results (something in vegastrike, not saying no symbol info), type "finish" which will finish the code in that part of the stack, each time going down one item. keep doing the

Code: Select all

bt
finish
bt

series until you get a good backtrace.

At some point, it will make its way back into vegastrike's code where it knows what's going on. When you are finally in vegastrike code (or at the point where you see a long printout), post the output of "bt full"

[Beowulf]

Two possibilities... I'll tell you how to figure out.

One thing might be that it is actually in a different thread. You can find out by doing "info threads"

You should see thread 1 as having an asterisk and inside of fprintf, like this.

Code: Select all

  3 Thread 1091017024 (LWP 8941)  0x00002b00dcba4bd8 in __lll_mutex_lock_wait
    () from /lib/libpthread.so.0
  2 Thread 1082149184 (LWP 8940)  0x00002b00dce7b037 in ioctl ()
   from /lib/libc.so.6
* 1 Thread 47282749079760 (LWP 8939)  0x00002b00dcba5881 in fprintf ()

There appears to be only one thread.

If the asterisk and fprintf is somewhere else (maybe thread 2 or 3), then you need to go to thread 1, which you can do by typing in gdb:

Code: Select all

thread 1
bt full

If the asterisk is in fact in thread 1, then the lack of debugging symbols is confusing GDB, but this is still fine with us.

Since the program is not crashing, but is only at a breakpoint, there is a solution for this. Until "bt" gives you meaningful results (something in vegastrike, not saying no symbol info), type "finish" which will finish the code in that part of the stack, each time going down one item. keep doing the

Code: Select all

bt
finish
bt

series until you get a good backtrace.

At some point, it will make its way back into vegastrike's code where it knows what's going on. When you are finally in vegastrike code (or at the point where you see a long printout), post the output of "bt full"

That doesn't gain me any new information:

Code: Select all

(gdb) bt
#0  0xb79625f6 in fprintf () from /lib/tls/i686/cmov/libc.so.6
#1  0xb2aba900 in _mesa_problem () from /usr/lib/dri/i915_dri.so
#2  0xb2a8db6a in ?? () from /usr/lib/dri/i915_dri.so
#3  0x00000000 in ?? ()
(gdb) finish
Run till exit from #0  0xb79625f6 in fprintf () from /lib/tls/i686/cmov/libc.so.6
Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
0xb2aba900 in _mesa_problem () from /usr/lib/dri/i915_dri.so
(gdb) bt
#0  0xb2aba900 in _mesa_problem () from /usr/lib/dri/i915_dri.so
#1  0xb2a8db6a in ?? () from /usr/lib/dri/i915_dri.so
#2  0x00000000 in ?? ()
(gdb) finish
Run till exit from #0  0xb2aba900 in _mesa_problem () from /usr/lib/dri/i915_dri.so
Please report at bugzilla.freedesktop.org
0xb2a8db6a in ?? () from /usr/lib/dri/i915_dri.so
(gdb) bt
#0  0xb2a8db6a in ?? () from /usr/lib/dri/i915_dri.so
#1  0x00000000 in ?? ()
(gdb) finish
Run till exit from #0  0xb2a8db6a in ?? () from /usr/lib/dri/i915_dri.so
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x0: Input/output error.

[ace123]

Try the same thing, except with "next" or "step" instead of "finish"

It should say "single stepping to end of function".

If all else fails do "stepi" with an argument of 100 or so to go 100 at a time... stepi will almost certainly work.

[Beowulf]

Stepping doesn't yield any more information, nor does next or stepi:

Code: Select all

(gdb) step
Single stepping until exit from function fprintf,
which has no line number information.
Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
0xb2aca900 in _mesa_problem () from /usr/lib/dri/i915_dri.so
(gdb) bt full
#0  0xb2aca900 in _mesa_problem () from /usr/lib/dri/i915_dri.so
No symbol table info available.
#1  0xb2a9db6a in ?? () from /usr/lib/dri/i915_dri.so
No symbol table info available.
#2  0x00000000 in ?? ()
No symbol table info available.

[ace123]

Sorry, I didn't make it clear enough.

I meant to keep typing step until all the functions on that list are gone... in your case that would be 3 or 4 times: once for fprintf, once for _mesa_problem, once for that weird 0x2something address, and after you single step out of that one the rest of the stack *should* show up.

If the last step fails to work (when you land on the one above 0x0000000 it complains about "failed to set breakpoint", then do the same process, but... Once you reach right above "0x0000000" instead keep typing the command "stepi 100" until it goes away. If stepi 100 fails to work after a few runs try increasing that number to 200 or 400 until finally it exits. The problem is if you make stepi by too large a number, it will skip past the relavent part of Vega Strike code that is causing the problem.

Just keep typing "bt" after you step or stepi until you get a list of 10 items with meaningful data (Vega Strike code with line numbers/function names).

If you make it down to the part that showed up as 0x0000000 without GDB saying something weird like "failed to set breakpoint" then the stack trace ought to work... I don't know how much Mesa corrupts the stack.

Sorry about making you go through so much work, but GDB can be quite tedious at times... if anyone knows a better way of debugging with GDB when it doesn't show symbols I would be interested.

[Beowulf]

Sorry about making you go through so much work, but GDB can be quite tedious at times... if anyone knows a better way of debugging with GDB when it doesn't show symbols I would be interested.

That's ok, I was rather worried I was getting on your nerves because I didn't figure gdb out myselves
I used gdb for a course at university but the programs we were working with were much simpler than vegastrike and I haven't done anything recently with gdb so much of what I knew about it is gone...
I'll make another try tomorrow, it's quite late here already.

[Beowulf]

OK, I think I have something useable:

Code: Select all

#0  0xb2b26c2f in _mesa_BlendFuncSeparateEXT () from /usr/lib/dri/i915_dri.so
No symbol table info available.
#1  0xb2b261f3 in _mesa_BlendFunc () from /usr/lib/dri/i915_dri.so
No symbol table info available.
#2  0x08ab884f in GFXBlendMode (src=SRCALPHA, dst=INVSRCALPHA) at src/gldrv/gl_state.cpp:348
        sfactor = 770
        dfactor = 771
#3  0x08860f40 in Animation::ProcessFarDrawQueue (farval=-3.40282347e+38) at src/gfx/animation.cpp:141
No locals.
#4  0x088cf672 in Mesh::ProcessZFarMeshes (nocamerasetup=false) at src/gfx/mesh_gfx.cpp:462
        defaultprogram = 0
        meshcolor = {r = 0.300000012, g = 0.300000012, b = 0.300000012, a = 1}
#5  0x08847313 in GameStarSystem::Draw (this=0xa9210e0, DrawCockpit=true) at src/star_system.cpp:491
        starttime = 1128.5678951740265
        par = (class Unit *) 0xfbd86a8
        alreadysetviewport = true
        setupdrawtime = 3.814697265625e-05
        drawtime = 22.972878932952881
        maxdrawtime = 0
        drawstartpos = {i = -10000000009000, j = -10029998.919193029, k = 500305.44443893433}
        key_iterator = {position = {i = -10000000009000, j = -10029998.919193029, k = 500305.44443893433}, radius = -0.0799999982,
  ref = {unit = 0x0, bolt_index = 0}}
        drawer = {<UnitWithinRangeLocator<UnitDrawer>> = {action = {gravunits = {_M_ht = {
          _M_node_allocator = {<__gnu_cxx::new_allocator<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> > >> = {<No data fields>}, <No data fields>}, _M_hash = {a = {<No data fields>}}, _M_equals = {<> = {<No data fields>}, <No data fields>},
          _M_get_key = {<> = {<No data fields>}, <No data fields>},
          _M_buckets = {<std::_Vector_base<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> >*,std::allocator<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> >*> >> = {
              _M_impl = {<std::allocator<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> >*>> = {<__gnu_cxx::new_allocator<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> >*>> = {<No data fields>}, <No data fields>},
                _M_start = 0xd661810, _M_finish = 0xd661b14, _M_end_of_storage = 0xd661b14}}, <No data fields>},
          _M_num_elements = 0}}, parent = 0x0, parenttarget = 0x0}, startkey = -10000000009000, radius = 500000000,
    maxUnitRadius = 0}, <No data fields>}
        unit = (class Unit *) 0x0
        parent = (Collidable *) 0xf9af208
        tmpcol = {r = 0, g = 0, b = 0, a = 1}
        processmesh = 1151.5412130355835
        neb = (class Nebula *) 0x8473f27
        ident = {r = {4.32861096e-42, 8.40779079e-43, 1.40129846e-45, 1.40129846e-45, -1.80972004, -2.08647641e-08, 3.801584e-33,
    4.32861096e-42, 0}, p = {i = 2.1219960874046598e-314, j = -0.73889541625976574, k = 6.5549168552279131e-311}}
        fintime = -10029998.919193029
        always_make_smooth = false
        precull_distance = 500000000
        DrawNearStarsLast = false
#6  0x08851740 in GameUniverse::StartDraw (this=0x99ae168) at src/universe.cpp:322
        x = 0
        y = 0
        w = 1
        h = 1
        i = 0
        lastStarSystem = (class StarSystem *) 0x0
        systime = -1.80979443
        numrunningsystems = 2
        nonactivesystemtime = 0.5
        sorttime = 59707
        howoften = 20
        numrunningsystems = 3
        deleteoldsystems = true
#7  0x08833b12 in main_loop () at src/main_loop.cpp:1102
No locals.
#8  0x08ac1973 in winsys_process_events () at src/gldrv/winsys.cpp:500
        event = {type = 1 '\001', active = {type = 1 '\001', gain = 0 '\0', state = 2 '\002'}, key = {type = 1 '\001',
    which = 0 '\0', state = 2 '\002', keysym = {scancode = 0 '\0', sym = SDLK_UNKNOWN, mod = KMOD_NONE, unicode = 0}}, motion = {
    type = 1 '\001', which = 0 '\0', state = 2 '\002', x = 0, y = 0, xrel = 0, yrel = 0}, button = {type = 1 '\001',
    which = 0 '\0', button = 2 '\002', state = 0 '\0', x = 0, y = 0}, jaxis = {type = 1 '\001', which = 0 '\0', axis = 2 '\002',
    value = 0}, jball = {type = 1 '\001', which = 0 '\0', ball = 2 '\002', xrel = 0, yrel = 0}, jhat = {type = 1 '\001',
    which = 0 '\0', hat = 2 '\002', value = 0 '\0'}, jbutton = {type = 1 '\001', which = 0 '\0', button = 2 '\002',
    state = 0 '\0'}, resize = {type = 1 '\001', w = 0, h = 0}, expose = {type = 1 '\001'}, quit = {type = 1 '\001'}, user = {
    type = 1 '\001', code = 0, data1 = 0x0, data2 = 0x0}, syswm = {type = 1 '\001', msg = 0x0}}
        key = 3081846772
        x = 161144192
        y = -1213120524
        state = false
        handle_unicode_kb = true
        keysym_to_unicode = {0 <repeats 256 times>}
        keysym_to_unicode_init = true
#9  0x08aa150c in GFXLoop (main_loop=0x8ac3a7c <bootstrap_first_loop()>) at src/gldrv/gl_init.cpp:602
        are_we_looping = true
        __PRETTY_FUNCTION__ = "void GFXLoop(void (*)())"
#10 0x0885278f in GameUniverse::Loop (this=0x99ae168, main_loop=0x8ac3a7c <bootstrap_first_loop()>) at src/universe.cpp:186
No locals.
#11 0x08ac556c in main (argc=1, argv=0xbfe7a9b4) at src/main.cpp:331
        temp = {<std::_Vector_base<std::vector<char, std::allocator<char> >,std::allocator<std::vector<char, std::allocator<char> > > >> = {
    _M_impl = {<std::allocator<std::vector<char, std::allocator<char> > >> = {<__gnu_cxx::new_allocator<std::vector<char, std::allocator<char> > >> = {<No data fields>}, <No data fields>}, _M_start = 0x99ac518, _M_finish = 0x99ac644,
      _M_end_of_storage = 0x99ac644}}, <No data fields>}

Does that make sense?

[ace123]

SWEET!!!! We might be getting somewhere.

I'm just failing to understand why glBlendFunc would cause this error, however.

Now just curious to check if this is the case, what command did you use to get past the 0x0000000 in the stack? If it was

If it was stepi, what number did you put there? If it was too high, it could have left the function causing the problem, so that might cause this backtrace to be wrong

Thing is, you should be able to binary search the number of stepi's (you know about how many total stepis you put there last time). If you did 1000 last time you should be able to go 500 and then 250 and then 125 until finally it leaves the function.

However, if it was just 50 instructions or so, I would trust that maybe it was glBlendFunc

Anyway I'll try to look into this since I know the general area it happens in

[ace123]

Interesting...
Where you broke is about 100 instructions after a call to "glUseProgram_p(0)"

If you indeed did use stepi 100 maybe try stepi 10 a few times to exit the loop and this may confirm this section.

Can I assume that you have already tried renaming the "programs" folder away?

[Beowulf]

SWEET!!!! We might be getting somewhere.

I'm just failing to understand why glBlendFunc would cause this error, however.

Now just curious to check if this is the case, what command did you use to get past the 0x0000000 in the stack? If it was

If it was stepi, what number did you put there? If it was too high, it could have left the function causing the problem, so that might cause this backtrace to be wrong

I used step until I reached the point where it complains about 0x00... After thatI only used a single stepi 100. Smaller values didn't get me anywhere even if used repeatetly.

[ace123]

What happens if you move away the "programs" folder in data4.x?

I'm going to try to set up a patchset to test out a few places in the code that are causing this error... but I would be curious if this solves the issue if you haven't already tried this?

[Beowulf]

What happens if you move away the "programs" folder in data4.x?

I'm going to try to set up a patchset to test out a few places in the code that are causing this error... but I would be curious if this solves the issue if you haven't already tried this?

It"s late here already so I"ll try this tomorrow---what effect does moving the programs folder out of the way have on vegastrike?

[loki1950]

The programs folder is where the shaders are kept so renaming or moving will disable shader support completely so ace can see if the shaders have anything to do with this issue.


Enjoy the Choice

[Beowulf]

I moved the programs directory out of the way but it doesn't appear to make a difference. Also here is the result if I use stepi 1 two times instead of stepi 100 which should be as close to the cause as we can get:

Code: Select all

Breakpoint 2, 0xb2a488a4 in _mesa_problem () from /usr/lib/dri/i915_dri.so
(gdb) bt
#0  0xb2a488a4 in _mesa_problem () from /usr/lib/dri/i915_dri.so
#1  0xb2a1bb6a in ?? () from /usr/lib/dri/i915_dri.so
#2  0x00000000 in ?? ()
(gdb) step
Single stepping until exit from function _mesa_problem,
which has no line number information.
Mesa 6.5.2 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x0: Input/output error.

(gdb) bt
#0  0xb2a1bb6a in ?? () from /usr/lib/dri/i915_dri.so
#1  0x00000000 in ?? ()
(gdb) step
Cannot find bounds of current function
(gdb) stepi 1
0xb2a1bb6c in ?? () from /usr/lib/dri/i915_dri.so
(gdb) bt
#0  0xb2a1bb6c in ?? () from /usr/lib/dri/i915_dri.so
#1  0x00000000 in ?? ()
(gdb) stepi 1
0xb2a1bb6d in ?? () from /usr/lib/dri/i915_dri.so
(gdb) bt
#0  0xb2a1bb6d in ?? () from /usr/lib/dri/i915_dri.so
#1  0x08a9e9bd in GFXActivateShader (program=0x0) at src/gldrv/gl_program.cpp:275
#2  0x088cf3b7 in Mesh::ProcessZFarMeshes (nocamerasetup=false) at src/gfx/mesh_gfx.cpp:438
#3  0x08847313 in GameStarSystem::Draw (this=0xcaa0010, DrawCockpit=true) at src/star_system.cpp:491
#4  0x08851740 in GameUniverse::StartDraw (this=0x99ae168) at src/universe.cpp:322
#5  0x08833b12 in main_loop () at src/main_loop.cpp:1102
#6  0x08ac1973 in winsys_process_events () at src/gldrv/winsys.cpp:500
#7  0x08aa150c in GFXLoop (main_loop=0x8ac3a7c <bootstrap_first_loop()>) at src/gldrv/gl_init.cpp:602
#8  0x0885278f in GameUniverse::Loop (this=0x99ae168, main_loop=0x8ac3a7c <bootstrap_first_loop()>) at src/universe.cpp:186
#9  0x08ac556c in main (argc=1, argv=0xbfb7a884) at src/main.cpp:331
(gdb) bt full
#0  0xb2a1bb6d in ?? () from /usr/lib/dri/i915_dri.so
No symbol table info available.
#1  0x08a9e9bd in GFXActivateShader (program=0x0) at src/gldrv/gl_program.cpp:275
        defaultprogram = 0
        curprogram = 0
        lastprogram = 0x0
#2  0x088cf3b7 in Mesh::ProcessZFarMeshes (nocamerasetup=false) at src/gfx/mesh_gfx.cpp:438
        defaultprogram = -1078484264
        meshcolor = {r = 0, g = 0, b = 0, a = 0}
#3  0x08847313 in GameStarSystem::Draw (this=0xcaa0010, DrawCockpit=true) at src/star_system.cpp:491
        starttime = 99.038297176361084
        par = (class Unit *) 0xfb85c18
        alreadysetviewport = true
        setupdrawtime = 0.028386831283569336
        drawtime = 0.25620508193969727
        maxdrawtime = 0
        drawstartpos = {i = -10000000009000, j = -10029998.919193029, k = 500305.44443893433}
        key_iterator = {position = {i = -10000000009000, j = -10029998.919193029, k = 500305.44443893433}, radius = -0.0799999982,
  ref = {unit = 0x0, bolt_index = 0}}
        drawer = {<UnitWithinRangeLocator<UnitDrawer>> = {action = {gravunits = {_M_ht = {
          _M_node_allocator = {<__gnu_cxx::new_allocator<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> > >> = {<No data fields>}, <No data fields>}, _M_hash = {a = {<No data fields>}}, _M_equals = {<> = {<No data fields>}, <No data fields>},
          _M_get_key = {<> = {<No data fields>}, <No data fields>},
          _M_buckets = {<std::_Vector_base<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> >*,std::allocator<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> >*> >> = {
              _M_impl = {<std::allocator<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> >*>> = {<__gnu_cxx::new_allocator<__gnu_cxx::_Hashtable_node<std::pair<void* const, UnitDrawer::empty> >*>> = {<No data fields>}, <No data fields>},
                _M_start = 0x11f60d30, _M_finish = 0x11f61034, _M_end_of_storage = 0x11f61034}}, <No data fields>},
          _M_num_elements = 0}}, parent = 0x0, parenttarget = 0x0}, startkey = -10000000009000, radius = 500000000,
    maxUnitRadius = 0}, <No data fields>}
        unit = (class Unit *) 0x0
        parent = (Collidable *) 0xf95ca60
        tmpcol = {r = 0, g = 0, b = 0, a = 1}
        processmesh = 99.924643039703369
        neb = (class Nebula *) 0x8473f27
        ident = {r = {4.32861096e-42, 8.40779079e-43, 1.40129846e-45, 1.40129846e-45, -1.4346838, -2.09084199e-08, 3.80161632e-33,
    4.32861096e-42, 0}, p = {i = 2.1219960874046598e-314, j = -0.092343807220458998, k = 6.5549168552279131e-311}}
        fintime = 0
        always_make_smooth = false
        precull_distance = 500000000
        DrawNearStarsLast = false
#4  0x08851740 in GameUniverse::StartDraw (this=0x99ae168) at src/universe.cpp:322
        x = 0
        y = 0
        w = 1
        h = 1
        i = 0
        lastStarSystem = (class StarSystem *) 0x0
        systime = -1.43475819
        numrunningsystems = 0
        nonactivesystemtime = 0
        sorttime = 0
        howoften = 0
        numrunningsystems = 0
        deleteoldsystems = false
#5  0x08833b12 in main_loop () at src/main_loop.cpp:1102
No locals.
#6  0x08ac1973 in winsys_process_events () at src/gldrv/winsys.cpp:500
        event = {type = 17 '\021', active = {type = 17 '\021', gain = 234 'ê', state = 81 'Q'}, key = {type = 17 '\021',
    which = 234 'ê', state = 81 'Q', keysym = {scancode = 25 '\031', sym = 771751938, mod = 3216483784, unicode = 42436}},
  motion = {type = 17 '\021', which = 234 'ê', state = 81 'Q', x = 25, y = 0, xrel = 2, yrel = 11776}, button = {type = 17 '\021',
    which = 234 'ê', button = 81 'Q', state = 8 '\b', x = 25, y = 0}, jaxis = {type = 17 '\021', which = 234 'ê', axis = 81 'Q',
    value = 25}, jball = {type = 17 '\021', which = 234 'ê', ball = 81 'Q', xrel = 25, yrel = 0}, jhat = {type = 17 '\021',
    which = 234 'ê', hat = 81 'Q', value = 8 '\b'}, jbutton = {type = 17 '\021', which = 234 'ê', button = 81 'Q', state = 8 '\b'},
  resize = {type = 17 '\021', w = 25, h = 771751938}, expose = {type = 17 '\021'}, quit = {type = 17 '\021'}, user = {
    type = 17 '\021', code = 25, data1 = 0x2e000002, data2 = 0xbfb7a5c8}, syswm = {type = 17 '\021', msg = 0x19}}
        key = 3081871348
        x = 161144192
        y = -1213095948
        state = false
        handle_unicode_kb = true
        keysym_to_unicode = {0 <repeats 256 times>}
        keysym_to_unicode_init = true
#7  0x08aa150c in GFXLoop (main_loop=0x8ac3a7c <bootstrap_first_loop()>) at src/gldrv/gl_init.cpp:602
        are_we_looping = true
        __PRETTY_FUNCTION__ = "void GFXLoop(void (*)())"
#8  0x0885278f in GameUniverse::Loop (this=0x99ae168, main_loop=0x8ac3a7c <bootstrap_first_loop()>) at src/universe.cpp:186
No locals.
#9  0x08ac556c in main (argc=1, argv=0xbfb7a884) at src/main.cpp:331
        temp = {<std::_Vector_base<std::vector<char, std::allocator<char> >,std::allocator<std::vector<char, std::allocator<char> > > >> = {
    _M_impl = {<std::allocator<std::vector<char, std::allocator<char> > >> = {<__gnu_cxx::new_allocator<std::vector<char, std::allocator<char> > >> = {<No data fields>}, <No data fields>}, _M_start = 0x99ac518, _M_finish = 0x99ac644,
      _M_end_of_storage = 0x99ac644}}, <No data fields>}

[ace123]

Thanks. That looks like the culprit then.

We ought to just put some sort of if statements around the call to activate/deactivate shaders.

[Beowulf]

Would you post a note here once you think this is fixed so I can test it?