Solving glFlush segfault issues on recent Mesa (with a cluebit for NGD)

[Arafails]

In the most recent version of Regnum Online, the issue causing this crash ahs been patched, so this workaround should be no longer necessary

Because people with newer cards can't use the chroot workaround, here's an alternative (hopefully to be obsoleted soon. Clue to NGD: Don't call glFlush until you have a working context!).

Anyhow, a workaround. Download from clanigi.net.

Instructions for use:

Untar the file. This will create a glworkaround directory

glwa64.so and glwa32.so are prebuilt libraries for 64-bit and 32-bit systems respectively. You should be able to use them directly, no guarantees for glwa32.so. I'd suggest copying one of these to your regnum directory (from herein assumed to be ~/regnum), although it's not necessary.

Alternatively running make will compile glwa.so from the included source code, and you can copy that.

Run rolauncher (or the game client directly, whichever you prefer) with the correct .so preloaded. Remember you must use an absolute pathname if the .so is not in a standard library directory. So for example if you'd copied the 64-bit library to your ~/regnum directory, you'd run

LD_PRELOAD=~/regnum/glwa64.so ~/regnum/rolauncher

and everything should be hunky-dory, but mileage will vary (bash expansion converts ~ in the contents of ${HOME} , you may wish to put the full path to your home directoy in instead, eg /home/fudje/regnum/glwa.so for me).

Extra overhead is only one stack frame (using function pointers it skips past the check once it's found a context), so there shouldn't be a noticeable performance penalty.

Only tested on Radeon r600 with kernel 2.6.32-rc5 + airlied's drm-next and mesa git from of Oct 17, which gives interesting results thanks to texture compression bugs (screenshot attached, but don't expect this kind of corruption unless you have a recent ATi card and very recent opensource drivers).

[FUCKITYFUCK]

Thank you! It solved the SIGSEGV problem for me! (:

[w_larsen]

dmd@dmd-desktop:~/Desktop/hh$ LD_PRELOAD=~/regnum/glwa32.so ~/regnum/rolauncher
/home/dmd/regnum/rolauncher: symbol lookup error: /home/dmd/regnum/glwa32.so: undefined symbol: _glapi_Context

will look into it after short break.

[Arafails]

Originally Posted by w_larsen

dmd@dmd-desktop:~/Desktop/hh$ LD_PRELOAD=~/regnum/glwa32.so ~/regnum/rolauncher
/home/dmd/regnum/rolauncher: symbol lookup error: /home/dmd/regnum/glwa32.so: undefined symbol: _glapi_Context

will look into it after short break.

Did you use the included binary? Sounds like the sort of error I'd expect; Compiling 32-bit libraries on a 64-bit system can be somewhat dubious;

Having said which, it looks like I may have uploaded an incorrect source version. Unfortunately I can't re-upload right now, so.... Even if it works there'll be a better version up tomorrow.

[w_larsen]

i used the included binary and compiled from source too. both gave same error.

[Arafails]

Originally Posted by w_larsen

i used the included binary and compiled from source too. both gave same error.

Can you run `nm -D /usr/lib/libGL.so.1 | grep _glapi_' and post the results here? Also your libgl / mesa version (If you're not using mesa's libGL you won't have any _glapi_* symbols, and this is moot anyway).

[onemyndseye]

You fkn rock mate!!! Will try this out on my old lappy.

[Arafails]

Okay download is available again at http://www.clanigi.net/downloads/glworkaround.tar.gz with correct version. You will need a Mesa3D libGL (or there will be no _glapi_* symbols, and the nvidia and ati ones seem to not care about contexts not being open anyway), and due to the somewhat hackish nature of this workaround that it'll help is a matter of chance. Especially on 32-bit systems with the precompiled version.

If you know you have Mesa3D libGL and you're still getting errors resolving _glapi_get_context it may help to install debugging symbols (on debian or ubuntu, `apt-get install libgl1-mesa-glx-dbg libgl1-mesa-dri-dbg').

Any which way the ultimate solution in this instance is for NGD to review their libopengl_api.so and remove calls to context-dependent OpenGL functions where there is no context, like this one (that causes the startup crash):

#0  glFlush () at ../../../src/mesa/x86-64/glapi_x86-64.S:7663
#1  0x00007ffff5fc8d05 in Engine3D::RenderizerGL::change_videomode(int, int, int, bool) () from libs/libopengl_api.so
#2  0x00007ffff5fa33aa in Engine3D::RenderizerGL::init_graphics_system(int, int, int, bool, bool) () from libs/libopengl_api.so
#3  0x00007ffff6fca0fb in DisplayEntity::creation_notify(Message*) ()
   from libs/libcommon_entities.so
#4  0x00007ffff580da76 in EntityManager::initialize_entity_as_custom_type(char const*, int, char const*, Message*, Entity*) () from libs/libentity_system.so
#5  0x00007ffff7e8ce6f in GameClient::initialize_entities() ()
   from libs/libregnum_client.so
#6  0x00007ffff7e8fa97 in GameClient::init(int, char**) ()
   from libs/libregnum_client.so
#7  0x00007ffff7e90f49 in GameClient::GameClient(int, char**) ()
   from libs/libregnum_client.so
#8  0x000000000040126e in main ()

Probably for that one it's a simple case of initializing OpenGL before the call to Engine3D::RenderizerGL::change_videomode()

[surak]

Wow. Nice. I don't think that glFlush has anything to do there. Must be a really ooooooooooold line of code. It's not like there is no context, but it's not currently active.

Blah. I'm removing it.
Expect a little patch soon ^^

[onemyndseye]

Hail Surak, Executioner of acient bugs!!! :P