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 (http://www.clanigi.net/downloads/glworkaround.tar.gz).

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]

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. :angel1:

[w_larsen]

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

[Arafails]

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(ch ar 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

[Arafails]

Yay! Results!

[onemyndseye]

I can confirm this working on the following system:

Ubuntu Jaunty
Kernel: 2.6.30
Mesa: 7.4
Xorg: 7.4

Video hardware: ATI Radeon 9000 /w Opensource drivers


Good job mate!! you have officially close this nearly year old issue!!

[imefisto_foro]

Can I translate your solution and post it in the spanish forum?

[Arafails]

Can I translate your solution and post it in the spanish forum?
I don't see any reason why not.

[antoniomiguel]

This solved my trouble, thanks very much Arafails!

[onemyndseye]

Arafails -

with your permission I will include your lib as a alternate in the next debian package update (After current special event) until such time as NGD patches this bug.

[Arafails]

An alternate won't work very well, or at all, as the library doesn't work like that; It literally only overrides the symbol glFlush until such point as the real glFlush will actually work, that's why it's so small.

What you could do is include /etc/ld.so.preload in the package with the path to the binary included, or package a launcher that prepended the library to the LD_PRELOAD path, for example:
#!/bin/sh

LD_PRELOAD="${LIBDIR}/glwa.so ${LD_PRELOAD}"

exec ${BINDIR}/rolauncher.real

I would really recommend the launcher over anything else (writing /etc/ld.so.preload could well clobber important stuff).

The full workings of this is released without any licence agreement. You may do with it what you will, use it at your own risk.

. . .

Interestingly enough the new tech. version of Regnum on Amun has this problem fixed already, maybe we see update for live servers before too long ;)

[surak]

Hi there,

The little patch has just been uploaded. Please test & enjoy (if it works :P ) :)

[onemyndseye]

An alternate won't work very well, or at all, as the library doesn't work like that; It literally only overrides the symbol glFlush until such point as the real glFlush will actually work, that's why it's so small.

What you could do is include /etc/ld.so.preload in the package with the path to the binary included, or package a launcher that prepended the library to the LD_PRELOAD path, for example:
#!/bin/sh

LD_PRELOAD="${LIBDIR}/glwa.so ${LD_PRELOAD}"

exec ${BINDIR}/rolauncher.real

I would really recommend the launcher over anything else (writing /etc/ld.so.preload could well clobber important stuff).

The full workings of this is released without any licence agreement. You may do with it what you will, use it at your own risk.

. . .

Interestingly enough the new tech. version of Regnum on Amun has this problem fixed already, maybe we see update for live servers before too long ;)



Yes, sorry for not being clear. The package uses a wrapper script to call rolauncher and has a config file for the wrapper at /etc/default/regnum-online. I was going to add an option to this config for the lib to be preloaded. Not a true alt.



Hi there,

The little patch has just been uploaded. Please test & enjoy (if it works :P ) :)



Surak - Thanks for the patch will test today

[Arafails]

Hi there,

The little patch has just been uploaded. Please test & enjoy (if it works :P ) :)
Hurrah! More Results!

Works for me.

[imefisto_foro]

Hi there,

The little patch has just been uploaded. Please test & enjoy (if it works :P ) :)

Please, yell at the four winds (and spanish forum too).

[Ferente]

I'm still having troubles. I've done a normal installation, and still getting the "too old" error. So i've put the driconf workaround, and everything worked fine, but after few seconds playing i got SISEGV fault :(

My hardware conf is:

Intel Core 2 Duo T7250 at 2GHz;
ATI Mob Radeon X2300, open radeon 6.12.99 (git 29/9/09), mesa 7.6;
2Gb DDR2 Ram;
Ubuntu 9.10 Karmic, Kernel 2.6.31.

It works only with the option "Force Safe Mode". I attached a crash backtrace.

[Arafails]

Ferente, that crash looks like it could be a bug with your 3D driver, or it could be some numpty passing invalid data to glBufferSubDataARB (which is easy to do, although I've never seen it segfault before, normally you just get bizarre geometry).

Either way, it is not related to the issue presented in this thread, and I'd suggest starting a new thread for it.

Cheers :)

[Ferente]

Ferente, that crash looks like it could be a bug with your 3D driver, or it could be some numpty passing invalid data to glBufferSubDataARB (which is easy to do, although I've never seen it segfault before, normally you just get bizarre geometry).

Either way, it is not related to the issue presented in this thread, and I'd suggest starting a new thread for it.

Cheers :)

Mmm, i'm not sure but ok.. I played a lot on lin before with closed drivers on my ati, and when i was forced to use open ones i had same kind of troubles as yours..

[onemyndseye]

maybe give libxtc a shot..


If you are Debina/Ubuntu:

cd ~
wget http://debian-multimedia.org/pool/main/libt/libtxc-dxtn/libtxc-dxtn0_0.070518-0.1_i386.deb
sudo dpkg -i libtxc-dxtn0_0.070518-0.1_i386.deb