#113 gluquadrics segfault when used together with sockets

v2.0
closed-out-of-date
GLU (21)
5
2004-09-14
2004-08-30
No

I am running a game in which I use gluQuadrics and
sockets (raw). I used to run into segfaults in socket
calls until I removed all gluDeleteQuadric calls. Now
the program runs fine on my machine, but on my coworker
machine the program crashes on calls to
gluCylinder/gluSphere.
Both machines are running pyopengl 2.0.44 on gentoo.

Thus I concluded the sockets library and the opengl
library are probably overwriting each other's data. I
thought for a moment it could be the garbage collector
(something could have forgotten to increase
references), but it crashes even if I call gc.disable()

the sockets code I am using is:

def call(self,arg):
client=socket(AF_INET, SOCK_STREAM)
client.connect(self.server)
wfile=client.makefile("wb",0)
rfile=client.makefile("rb",-1)
dump(arg,wfile)
res=load(rfile)
wfile.close()
rfile.close()
client.close()
return res

the quadrics code is just the good old
x=gluNewQuadric()
gluSphere(x,...)
#gluDeleteQuadric(x)
#deletequadric is commented because of the previous crashes

Thank you

Discussion

    • assigned_to: nobody --> mcfletch
     
  • Logged In: YES
    user_id=34901

    Would be very helpful to have a test script that shows the
    failure, rather than requiring me to build one from a
    general description like this ;) .

    First suggestion, of course, would be to update PyOpenGL to
    2.0.1.08 to get the bug-fixes since 2.0.0. I really should
    get the updated .ebuild put in to Gentoo one of these days I
    suppose.

     
  • Logged In: YES
    user_id=624873

    http://www.ic.unicamp.br/~ra002388/capivar-strip.tar.gz
    http://www.ic.unicamp.br/~ra002388/capivar-single.tar.gz

    I generated two stripped versions of the faulty program: one
    that uses sockets, and one that does not. A similar program
    in pure C works normally.

    The behaviour of these programs in my and my friend's
    machine are like this:

    In my machine:
    capivar-strip.tar.gz
    This client-server program raises a segfault if I use
    gluDeleteQuadric() after my use of the quadricobj. It runs
    normally (but probably leaking memory) if I comment the
    gluDeleteQuadric() calls.
    capivar-single.tar.gz
    This non-socket program runs normally with or without
    gluDeleteQuadric().

    In my friends machine even the non-socket program without
    gluDeleteQuadric() crashes.

    I'll try the new version today (I've just read it has new
    semantics for gluDeleteQuadric(), so it might help my case)

     
  • Logged In: YES
    user_id=624873

    Mea culpa, mea maxima culpa (maybe)

    With the new version of pyopengl (2.0.1) it works here on my
    machine (but, as I understand it, gluDeleteQuadric() on
    2.0.1 is only a stub, real deletion ocurring only when the
    variable is garbage-collected).

    As of my friend's machine, we discovered the crash was due
    to a SIGFPE, and managed to reproduce the gluSphere bug in C
    (A complex game with many spheres (all generated with
    quadrics) was working, but a simple 20 liner with one call
    to gluSphere() crashed. go figure...). So, it seems his GLU
    installation is flaky.

    So, as it seems, the only _possibly_ remaining bug is
    related to gluDeleteQuadric() in conjunction with sockets.
    But, as it IS working in the new version, fell free to close
    this bug.

     
  • Logged In: YES
    user_id=34901

    gluDeleteQuadric was turned into a null-stub to avoid these
    kinds of crashes, so it's not *too* surprising that it
    avoids the crash.

    Anyway, glad it's working for you with 2.0.1. Marking the
    issue closed.

     
    • status: open --> closed-out-of-date