2
\$\begingroup\$

I'm using pyglet for game development, and sometimes encounter "bus errors". They are not consistently repeatable, and whenever I try to do simple debugging (eg move/remove variables, etc), the errors will eventually disappear entirely. I feel like I am encountering the notorious "heisenbug" class of errors.

Intuitively, I feel like the problem is likely due to pyglet/opengl/video card interaction, but of course this is only a hunch. So my question is: how do I debug this kind of problem?

\$\endgroup\$
8
  • \$\begingroup\$ I guess you need some kind of equivalent of the good old "core dump"+gdb. \$\endgroup\$
    – o0'.
    Dec 15, 2011 at 15:33
  • \$\begingroup\$ Are you making any OpenGL calls yourself, or just via pyglet calls? \$\endgroup\$
    – Kylotan
    Dec 15, 2011 at 16:30
  • \$\begingroup\$ @Lohoris well, I did use gdb once, but didn't understand what to do with it; is that all I should be doing in this case? \$\endgroup\$ Dec 15, 2011 at 19:11
  • \$\begingroup\$ @Kylotan all are pyglet calls \$\endgroup\$ Dec 15, 2011 at 19:12
  • 1
    \$\begingroup\$ @Lohoris sounds like an answer :) If you'd like to elaborate a bit in an answer below, and/or point me to some URLs, I'll accept your answer. \$\endgroup\$ Dec 16, 2011 at 13:23

1 Answer 1

0
\$\begingroup\$

The most straightforward thing to do is to run your game through a debugger. pdb is python's default debugger, but IIRC there are good alternatives, such as bpython. Once an error happens, you'll be in the python's console and be able to debug the problem.

Since a "bus error" is, unless I'm not mistaken, something similar to a good old "segmentation fault", I guess you could instead somehow have it drop a core dump and analyze that, which is a less invasive method than running through a debugger... but unless you find quick and easy instruction about how to do that, I wouldn't bother.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .