Could you try with newer mesa (dri driver/libGL)? Hard to tell what's going on, but this could also happen if your libGL and dri drivers are out of sync.

I got the same error with Mesa 6.5.3 and Mesa 6.5.2:

libGL warning: 3D driver claims to not support visual 0x4b
Warning:  Producer::RenderSurface, under the X11 environment
          has tested the glXWaitVideoSyncSGI extension and found it
          to not be working properly.  This does not necessarily mean
          that glXSwapBuffers will not block on VSYNC, but it does mean
          that the CPU bound application will not be able to synchronize
          with the graphics video retrace signal.  Most operations will work
          fine.
Mesa 6.5.3 implementation error: User called no-op dispatch function (an unsupported extension function?)
Please report at bugzilla.freedesktop.org
...
FRAGMENT glCompileShader "" FAILED
...
glLinkProgram "" FAILED
...
libGL warning: 3D driver claims to not support visual 0x4b
Speicherzugriffsfehler (Segmentation fault)

This error happens on an Asus M6Ne wich has an ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]. 
If you want to reproduce it, try this applikation :
http://robot.informatik.uni-leipzig.de/software/?lang=en

The application works if started with the option -no-shadow

As far as I know, the GLSL compiler support in Mesa is still maturing. Most of the DRI drivers don't support it yet.  As for the first problem, you could try running the program with GDB and setting a breakpoint in _mesa_problem, then getting a backtrace. This should tell you which GL command caused the no-op dispatch. 

Here you go :
Breakpoint 2, _mesa_problem (ctx=0x0,
    fmtString=0xb6c8a780 "User called no-op dispatch function (an unsupported extension function?)") at main/imports.c:969
969     main/imports.c: No such file or directory.
        in main/imports.c
Current language:  auto; currently c
(gdb) bt
#0  _mesa_problem (ctx=0x0,
    fmtString=0xb6c8a780 "User called no-op dispatch function (an unsupported extension function?)") at main/imports.c:969
#1  0xb6b26fd8 in generic_nop () at main/context.c:970
#2  0xb7c29a43 in osg::GL2Extensions::glCreateShader () from /usr/lib/libosg.so
#3  0xb7c3c839 in osg::Shader::PerContextShader::PerContextShader () from /usr/lib/libosg.so
#4  0xb7c3d6b6 in osg::Shader::getPCS () from /usr/lib/libosg.so
#5  0xb7c3d8f3 in osg::Shader::compileShader () from /usr/lib/libosg.so
#6  0xb7c2f6c4 in osg::Program::compileGLObjects () from /usr/lib/libosg.so
#7  0xb7c5afa3 in osg::StateSet::compileGLObjects () from /usr/lib/libosg.so
#8  0xb7d47bda in osgUtil::GLObjectsVisitor::apply () from /usr/lib/libosgUtil.so
#9  0xb7d47cd8 in osgUtil::GLObjectsVisitor::apply () from /usr/lib/libosgUtil.so
#10 0xb7ea5787 in osg::NodeVisitor::apply () from /usr/lib/libosgProducer.so
#11 0xb7bf550e in osg::Group::accept () from /usr/lib/libosg.so
#12 0xb7bf3b61 in osg::Group::traverse () from /usr/lib/libosg.so
#13 0xb7d47d00 in osgUtil::GLObjectsVisitor::apply () from /usr/lib/libosgUtil.so
#14 0xb7ea5787 in osg::NodeVisitor::apply () from /usr/lib/libosgProducer.so
#15 0xb7bf550e in osg::Group::accept () from /usr/lib/libosg.so
#16 0xb7bf3b61 in osg::Group::traverse () from /usr/lib/libosg.so
#17 0xb7d47d00 in osgUtil::GLObjectsVisitor::apply () from /usr/lib/libosgUtil.so
#18 0xb7ea5787 in osg::NodeVisitor::apply () from /usr/lib/libosgProducer.so
#19 0xb7bf550e in osg::Group::accept () from /usr/lib/libosg.so
#20 0xb7bf3b61 in osg::Group::traverse () from /usr/lib/libosg.so

Does glxinfo say that GL_ARB_vertex/fragment_shader is supported?  It won't for the R300 driver.  I suspect that your game is trying to use the shading language without first checking that it's supported.

This really looks like what Brian said: the app is trying to use shaders on a driver that doesn't claim to support them, and failing in the expected way.  Of course, the driver does support GLSL by now.