[osg-users] Loading shaders - internal corruption?

[Jean-Sébastien Guay]

Hi all,

When loading and applying shaders in my app, I sometimes get error
messages like this:

glLinkProgram "DustParticleProgram" FAILED
Program "DustParticleProgram" infolog:
Fragment info
-------------
(0) : error C0000: syntax error, unexpected $end at token "<EOF>"
(0) : error C0501: type name expected at token "<null atom>"
(0) : error C9000: internal corruption, aborting

I've debugged into OSG when it compiles the shader and links the
program, and the fragment shader has proper source. But it looks as if
the GLSL compiler isn't getting this source correctly, it thinks it's
empty or something. I don't know what could cause this kind of problem.

This only happens sometimes, but once it starts happening I can try and
reload the shader as many times as I want, it'll keep on giving that
error (and always on the same shader/program!). Restarting the
application, the error doesn't show up anymore (at least not at the
start). But it's the same shader!

Has anyone seen something like this before? Perhaps it's a driver bug?
I'm already at the most recent version. If anyone has any ideas about
this I'd appreciate any info you have.

Thanks in advance,

J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

Hi J-S,

I rather sounds like a driver bug to me. One way to double check that
the OSG is passing the right data to OpenGL would be capture the
shaders output and pointers to a file and see if they remain valid.

Also running the application in a memory tracking tool would be a useful step.

Finally trying a different driver or different shaders to see if that
has any influence.

Robert.

[Jean-Sébastien Guay]

Hi Robert,

> I rather sounds like a driver bug to me. One way to double check that
> the OSG is passing the right data to OpenGL would be capture the
> shaders output and pointers to a file and see if they remain valid.
>
> Also running the application in a memory tracking tool would be a useful step.

I'll run in gDEBugger to see if I can reproduce the error and if it can
give me more info.

> Finally trying a different driver or different shaders to see if that
> has any influence.

As I said, between runs of the program the same shader might cause the
error or might not. But perhaps it's a combination of factors, I've got
many other shaders going on at the same time.

Thanks for your input,