Okay, I've added a check typemap for this that appears to solve the
problem. Looking at the code, I can see at least a few more instances
where Tarn wasn't checking for array-size/non-null conditions, so
there's at least a few more situations like this that will arise. For
now, anything which is defined as having "sometype *v" as it's signature
is getting void-checked and raising an error on that condition.
Why didn't I just modify the conversion routine?
There may be situations where the declaration *shouldn't* be
null-checked (that is, where NULL is a valid input), i.e. the fix
may actually break some code and making it easy to fix those
situations requires that the conversion routine not include the
checking support. The entire OpenGLContext test suite passes (at
least, runs as expected) with the changes, so it seems to work in
the common cases, anyway.
As a note, introducing this finally explained a long-standing bug with a
test-script, namely that a missing combine callback to GLU's
tessellation mechanism was returning a None, so was passing a NULL
pointer to gluVertex2fv.
Thanks for the report,
Mike
Maciej Kalisiak wrote:
>Quick disclaimer: I haven't updated my PyOpenGL in some time; version file
>shows 2.0.1.03. Alas, updating right now is not an option (lack of time,
>especially if upgrade doesn't go smoothly)
>
>I've noticed that glVertex2fv, and quite possibly the other vector forms of
>glVertex, do not handle gracefully the case when they are (erroneously) handed
>"None" instead of an actualy vector/sequence. I get a segfault; an exception
>(i.e., arg checking code) would be much more helpful.
>
>It could be that this is fixed in the latest versions of pyopengl, which I
>haven't tried, but I'm mailing this on the off chance that it isn't... it seems
>to me to be a rather rare bug, hence likely still present.
>
>
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
