Pointer to vertex arrays get unpinned to early
Posted Tuesday, 3 August, 2010 - 17:40 by Quoth| Project: | The Open Toolkit library |
| Version: | 1.0.0-rc1 |
| Component: | Documentation |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Hi!
I was just browsing to the code and stumbled over something.
Affected functions:
TexCoordPointer
ColorPointer
IndexPointer
NormalPointer
VertexPointer
The pointer gets pinned (GCHandle.Alloc), passed to GL and unpinned (ptr.Free()). But this pointer will be stored within GL's state until its used (see OpenGL Specification 1.1, chapter 2.8).
By unpinning within the *Pointer method the garbage collector is free to move the array around or even free it. We end up with undefined behaviour. Its perfectly OK (from the specification point of view) to set the pointer once and let it there unchanged for a long time.
The correct moment to unpin it would be when the pointer within GL state is changed, for example by calling the *Pointer again. Note that there are other methods that do this implicitly.
I think would be diffcult for the wrapper to keep track of this, so I'd suggest to delegate it to the user. The correct pattern would then be that the user pins and unpins manually before passing the pointer to OpenTK.
Currently nothing about this problem is mentioned in the OpenTK documentation.
Comments
#1
This is a documentation issue. Functions that use client-side storage (e.g. vertex arrays) are dangerous in garbage-collected environments like .Net - there's little OpenTK can do about this.
The best solution is to use server-side storage instead (e.g. vertex buffer objects).
#2
Agreed.
I've seen that OpenTK offers lots of overloads that allow passing managed arrays and similar. If the user must do the pinning, this overloads are of no use. They are actually quite missleading.
I'd suggest marking all but those taking an IntPtr as [Obsolete]. This should give OpenTK users a hint that they have a bug in their code, without breaking compatibility.
#3
Information how to handle client-side Vertex Arrays can be found in the documentation. I don't think it's viable to document every possible pitfall with inline documentation. If we would go that road, we would have to add to every single gl function info like "you must query whether extension X and Y are supported", "it is an error to use this inside a begin-end block" and so on ...
#4
Agreed.