Processing 1.0 - Processing Discourse - Crash in glBindTexture?

We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.

Index › Programming Questions & Help › OpenGL and 3D Libraries › Crash in glBindTexture

‹ Previous Topic | Next Topic ›

Pages: 1

Crash in glBindTexture? (Read 1619 times)

Florian Echtler

Crash in glBindTexture?
May 5^th, 2010, 1:52pm

Hello everyone,

I have a really nasty problem regarding OpenGL and external libraries.

I'm using a native graphics/widget library which is also based OpenGL; I've built suitable Java/Processing wrappers and everything works fine
- under Linux
- under MacOS X
- and in my Windows 7 VM.

The native library also works in a native Windows when used standalone. However, here's the catch:

when I use the native widgets from Processing under native Windows only, the Java VM crashes with a segfault when calling Code:

glBindTexture()

.

So in some bizarre way, the OpenGL setup done by Processing on a native Windows installation interferes with the external OpenGL library in such a way that glBindTexture is messed up.

I know that this entire setup is pretty involved, but maybe someone might have a suggestion as to what the problem could be...?

Thanks,
Floe

Florian Echtler

Re: Crash in glBindTexture?
Reply #1 - May 6^th, 2010, 9:10am

All right, very shortly after my post, I've found the solution myself

I'll add it here for reference, in case anybody else runs into this sometime.

The reason for the crash is a combination of the three following things:
- my native lib calls OpenGL functions in setup() and draw()
- Processing calls setup() and draw() from two different threads (why?)
- the Windows-supplied opengl32.dll is a piece of crap which destroys the stack when it's called from two different threads

So the fix was to simply move the native library setup calls to the very first call of draw() -> everything is called from one thread only, end of story.

Floe

Quark

Re: Crash in glBindTexture?
Reply #2 - May 7^th, 2010, 12:56pm

Quote:

Processing calls setup() and draw() from two different threads (why)

I didn't know that, which means I don't have the answer and would also be interested in hearing from anyone who does. Mmmm I did read somewhere that the size() method gets called twice or something like that maybe that has something to do with it. Undecided

Quote:

So the fix was to simply move the native library setup calls to the very first call of draw() -> everything is called from one thread only, end of story.

This ties in with
Quote:

Always do the assignment/cast from g to pgl inside draw(), because 'g' may change from time to time. In addition, use the GL object returned by beginGL() for the same reason, that the GL context itself may have changed. In practice, I've not really seen this happen, but this is strongly encouraged to prevent things from crashing in a bad way (think blue screen/kernel panic kinds of bad ways).

which can be found on this page.

All good stuff

Pages: 1

‹ Previous Topic | Next Topic ›