Skip to main content
GameDev.net gamedev.net
🔒 Locked

Help me with C++ exceptions please (python may also be involved) (and OpenGL too)

Started by twix Aug 4, 2006 at 10:51 PM 3 replies 2.3k views
Original Post
twix
twix
I don't know if I'm doing something really stupid (I'm a noob), but I'm having a problem with exceptions that's driving me absolutely insane. [sad] I'm using SWIG to make a Python module in C++. I have GCC 4.1.1. Now, here's a little snippet of code:

void exTest()
{
	try
	{
		throw 1;
	}
	catch (int n)
	{
		std::cerr << "Yay!\n";
	}
}






I compile this with

g++ -I/usr/include/python2.4 -O0 -g3 -Wall -c -fmessage-length=0 -fPIC






and eventually out comes a file called _libtrafsim.so. So I import it in Python (2.4.3), and try this function out.

>>> import libtrafsim
>>> libtrafsim.exTest()
*** glibc detected *** free(): invalid pointer: 0xb7c86668 ***
Aborted






[sad] Here's what Valgrind tells me:

>>> import libtrafsim
>>> libtrafsim.exTest()
==10646==
==10646== Invalid free() / delete / delete[]
==10646==    at 0x401C029: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10646==    by 0x400E2AD: ___tls_get_addr (in /lib/ld-2.3.6.so)
==10646==    by 0x48E542A: (within /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8)
==10646==    by 0x48E5466: __cxa_get_globals (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8)
==10646==    by 0x48E4F4E: __cxa_allocate_exception (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8)
==10646==    by 0x46A2BB4: TrafSim::exTest() (Serialization.cpp:39)
==10646==    by 0x46ABAA1: _wrap_exTest (libtrafsim_wrap.cxx:2968)
==10646==    by 0x408765A: PyCFunction_Call (in /usr/lib/libpython2.4.so.1.0)
==10646==  Address 0x428E668 is not stack'd, malloc'd or (recently) free'd






Any clues as to what the deal might be, or what steps I can take to investigate further? [Edited by - twix on August 5, 2006 3:23:30 AM]
twix
twix
Breaking news --- the problem only occurs when I link in OpenGL (-lGL).

I have a feeling this must be something amazingly obvious, but I still don't get it...
twix
twix
Yeaaahhhh... so here's the rundown of the situation.

I can compile a module using that code snippet, load it into Python, and it works just fine. Add the -lGL flag, and it dies with that error.

Taking that same .so file and loading it into a normal C program makes it work correctly, even with the -lGL flag.

So we have:
SWIG/Python + exceptions ===> works
OpenGL + exceptions ===> works
SWIG/Python + OpenGL ===> works (it seems, since other code runs without errors)
SWIG/Python + OpenGL + exceptions ===> wtf

So I'm rather confused.
mvBarracuda
mvBarracuda
Prolly far too late but we finally found a workaround for this issue that seems to resolve the problem at least for some users who encounter it. We've encountered this issue with our engine as well. A bunch of bug reports and backtraces can be found at this thread:
http://forums.fifengine.de/index.php?topic=30.0

We found these bugreports at the debian bug tracker:
* #1
* #2

The second bugreport contains a workaround that involves getting a debug version of stdlibc++ and linking against this one:
Quote:
It's easy to work around in Debian: install libstdc++6-4.0-dbg, and then set LD_LIBRARY_PATH to have /usr/lib/debug first. That libstdc++ library, which comes from gcc 4.0, doesn't exhibit the problem.


It seems that this issue just happens on 64bit linux distros nowadays; at least our users don't encounter the problem when building our engine on 32bit systems. Furthermore it seems fixed on certain Linux distros; e.g. it's fine on Debian sid but segfaults with Debian etch.

We're planning to build up a database to collect information which parameters are responsible for the issue to show up. As soon as we collected enough information we'll try to get in contact with whoever might be able to solve it (prolly the libstdc++ maintainers) and lobby to investigate and address the issue.

More information coming soon :-)
-----PARPG - open source isometric 2d old school RPG still looking for interested contributors
mvBarracuda
mvBarracuda
Yonibear finally found a workaround for issue: explicitly link against libstdc++ before linking against the opengl libs. At least that worked fine for our testers.

Here is the filed bug report with some more information about the bug:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219

Hopefully we can provide a more detailed explanation soon.
-----PARPG - open source isometric 2d old school RPG still looking for interested contributors

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.