After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 132058 - gtkgl bus error on constructor to gtk.gl.Area
gtkgl bus error on constructor to gtk.gl.Area
Status: RESOLVED INVALID
Product: pygtk
Classification: Bindings
Component: general
1.99.x/2.0.x
Other All
: Normal major
: ---
Assigned To: Python bindings maintainers
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2004-01-21 04:13 UTC by Rick Muller
Modified: 2005-08-22 12:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rick Muller 2004-01-21 04:13:14 UTC
Obtained a bus error from the following code:
>>> import gtk.gl
>>> glarea = gtk.gl.Area((gtk.gl.RGBA, gtk.gl.DOUBLEBUFFER, gtk.gl.DEPTH_SIZE, 1))
Bus error

Here is a stack trace from gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x006a0ee0 in g_type_check_instance_cast ()
(gdb) where
  • #0 g_type_check_instance_cast
  • #1 _wrap_gtk_gl_area_share_new
    at gtkgl.override line 94
  • #2 type_call
    at Objects/ typeobject.c line 431
  • #3 PyObject_Call
    at Objects/ abstract.c line 1755
  • #4 do_call
    at Python/ceval.c line 3644
  • #5 call_function
    at Python/ ceval.c line 3460
  • #6 eval_frame
    at Python/ceval.c line 2116
  • #7 PyEval_EvalCodeEx
    at Python/ceval.c line 2663
  • #8 PyEval_EvalCode
    at Python/ceval.c line 537
  • #9 PyImport_ExecCodeModuleEx
    at Python/import.c line 621
  • #10 load_source_module
    at Python/import.c line 894
  • #11 load_module
    at Python/import.c line 1699
  • #12 import_submodule
    at Python/import.c line 2290
  • #13 load_next
    at Python/import.c line 2111
  • #14 import_module_ex
    at Python/import.c line 1957
  • #15 PyImport_ImportModuleEx
    at Python/import.c line 1998
  • #16 builtin___import__
    at Python/ bltinmodule.c line 45
  • #17 PyObject_Call
    at Objects/ abstract.c line 1755
  • #18 PyEval_CallObjectWithKeywords
    at Python/ceval.c line 3346
  • #19 eval_frame
    at Python/ceval.c line 1996
  • #20 PyEval_EvalCodeEx
    at Python/ceval.c line 2663
  • #21 PyEval_EvalCode
    at Python/ceval.c line 537
  • #22 run_node
    at Python/pythonrun.c line 1239
  • #23 PyRun_InteractiveOneFlags
    at Python/pythonrun.c line 731
  • #24 PyRun_InteractiveLoopFlags
    at Python/pythonrun.c line 664
  • #25 PyRun_AnyFileExFlags
    at Python/pythonrun.c line 627
  • #26 Py_Main
    at Modules/main.c line 415
  • #27 _start
    at /SourceCache/ Csu/Csu-45/crt.c line 267
  • #28 start

This code works on Linux, obviously
Comment 1 Christian Reis (not reading bugmail) 2004-01-21 10:58:09 UTC
Rick, if you're interested in helping fix this, try taking a look at
the code pointed out by frame 1, which is _wrap_gtk_gl_area_share_new
at gtkgl.override:94. 

I'm not sure any of the more active developers has easy access to a
Mac to be able to reproduce this, but the error could be obvious (it
*seems* like we're calling g_type_check_instance_cast() on a freed
pointer, to me) and if so "patches welcome" <wink>.
Comment 2 Rick Muller 2004-01-21 17:07:10 UTC
Okay, I'm doing my best to track this down, even though I've never done anything 
quite like this before, so forgive me if a lot of what I say is stating the obvious.

The relevant lines of code are in gtkgl.c here:

    if (!pygobject_check(py_share, &PyGtkGLArea_Type)) {
	if ( pygobject_get(py_share) != NULL )
	    share = GTK_GL_AREA(pygobject_get(py_share));
    } else if (py_share != Py_None) {
	PyErr_SetString(PyExc_TypeError, "share must be a GtkGLArea or None");
	return -1;
    }

in the function _wrap_gtk_gl_area_share_new() (which is the initializer of the 
gtk.gl.Area object).

the pygobject_check() macro seems to be the culprit here. In pygobject.h, this is 
defined as:
#define pygobject_check(v,base) (PyObject_TypeCheck(v,base))
where the latter macro is defined in <python2.3/object.h>, and almost certainly isn't 
the problem.

So, it would appear that the code is crashing because py_share doesn't point to 
anything, right? py_share is initialized to Py_None, and is then assigned to some value 
via PyArg_ParseTuple.

Given this clue, I decided to play around with the constructor. Recall that the test 
code was 
>>> import gtk.gl
>>> glarea = gtk.gl.Area((gtk.gl.RGBA, gtk.gl.DOUBLEBUFFER, gtk.gl.DEPTH_SIZE, 1))
which defaults to py_share (the second argument) = None. If, instead, I pass in 0:
>>> import gtk.gl
>>> glarea = gtk.gl.Area((gtk.gl.RGBA, gtk.gl.DOUBLEBUFFER, gtk.gl.DEPTH_SIZE, 
1),0)
the code doesn't give a bus error!

Can someone who knows more about this than I suggest a patch?
Comment 3 Christian Reis (not reading bugmail) 2004-01-22 20:07:14 UTC
ISTM that the line

    if (!pygobject_check(py_share, &PyGtkGLArea_Type)) {

is incorrect, and that it should in fact be

    if (pygobject_check(py_share, &PyGtkGLArea_Type)) {

since PyObject_Typecheck returns 1 when the argument is of the
specified type and 0 if not [*]. Otherwise the check for Py_None in
the following clause is bogus, right?

Can you give that a try and let me know?

[*] http://www.python.org/doc/current/ext/node33.html
Comment 4 Christian Reis (not reading bugmail) 2004-01-22 20:08:28 UTC
And if so, this error is not Mac-related at all, so update the OS
fields accordingly :-)
Comment 5 Rick Muller 2004-01-23 22:42:17 UTC
Christian, your suggestion to change the line

    if (!pygobject_check(py_share, &PyGtkGLArea_Type)) {

to

    if (pygobject_check(py_share, &PyGtkGLArea_Type)) {

worked. In fact, it gave an error to my "workaround code" where I set py_share to 0, 
telling me that py_share had to be either None or a glarea.

I changed the OS of this bug to "All". Can anyone confirm that this patch would work 
on other platforms, and explain why it wasn't a bug there>
Comment 6 Christian Reis (not reading bugmail) 2004-01-24 11:26:48 UTC
Possibly because nobody else has tested this before.

Johan, can you check this in and close this one for us? Thanks.
Comment 7 Rick Muller 2004-01-28 19:14:14 UTC
Okay, I tried the patch on Linux (RH9.0), using Python 2.3.2, pygtk
2.0, and PyOpenGL-2.0.1.07.

I made the test script a little bit more complex:


try:
    glarea = gtk.gl.Area((gtk.gl.RGBA, gtk.gl.DOUBLEBUFFER,
                          gtk.gl.DEPTH_SIZE, 1),None)
    print "Second arg = None succeeded"
except:
    print "Second arg = None failed"

try:
    glarea = gtk.gl.Area((gtk.gl.RGBA, gtk.gl.DOUBLEBUFFER,
                          gtk.gl.DEPTH_SIZE, 1))
    print "No second arg succeeded"
except:
    print "No second arg failed"

try:
    glarea = gtk.gl.Area((gtk.gl.RGBA, gtk.gl.DOUBLEBUFFER,
                          gtk.gl.DEPTH_SIZE, 1),0)
    print "Second arg = zero succeeded"
except:
    print "Second arg = zero failed"



Before the patch, all three Area() calls succeeded, which I believe is
incorrect (the last one should fail, since you need to supply either
None or nothing or a GLArea, but not the integer 0).

After the patch, the first two succeeded and the third failed, which I
believe is correct.

I believe that this patch can be safely committed.
Comment 8 Xavier Ordoquy 2004-02-24 21:41:53 UTC
gtkgl area code has been removed from the current cvs code which makes
this bug having no more sense.
Comment 9 Rick Muller 2004-02-29 19:05:09 UTC
Can we put the code back into the CVS archive? I'm currently maintaining a project 
that uses these widgets, and will be glad to maintain the codebase if necessary. I 
realize that the smart thing to do is to migrate my code from glarea to glext, but 
that's a headache for another month right now. Plus, the glext code wasn't in the 
standard bindings either, last time I checked.
Comment 10 Christian Reis (not reading bugmail) 2004-03-01 13:03:41 UTC
Would it be practical for you to maintain this code as a separate
package? That way you're not tied to the availability of the PyGTK
team and in general will have more flexibility with releases and changes.
Comment 11 Xavier Ordoquy 2004-03-01 13:18:54 UTC
Sounds ok to me. I'll ask to close the bug once the binding will be 
moved (probably this week end).