Boost.Python std::cerr segfault when built with -lGL
Hello, I'm using Boost.Python to create a python library. When I use -lGL in my linker flags, the first string I send to std::cerr results in an exception. When I leave -lGL out, everything is fine and std::cerr works with no problems. I get this problem when I add -lGL to the simplest Boost.Python sample program that has nothing to do with OpenGL. Any ideas? Does anybody else see this behavior? I'm on Gentoo Linux, using gcc 4.1.1, Python 2.4 and Boost 1.33. I tried Python 2.3 too and it's the same. -Gazi
Gazihan Alankus wrote:
Hello,
I'm using Boost.Python to create a python library. When I use -lGL in my linker flags, the first string I send to std::cerr results in an exception. When I leave -lGL out, everything is fine and std::cerr works with no problems. I get this problem when I add -lGL to the simplest Boost.Python sample program that has nothing to do with OpenGL. Any ideas? Does anybody else see this behavior?
I'm on Gentoo Linux, using gcc 4.1.1, Python 2.4 and Boost 1.33. I tried Python 2.3 too and it's the same.
(Is this 'GL' name specific to Gentoo ? On my distribution I would name it 'gl', i.e. all minor case.) Have you tried reducing your test case to the point where boost.python isn't part of the setup any more ? It doesn't sound as if your problem is related to neither Python nor boost, in any case. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
(Is this 'GL' name specific to Gentoo ? On my distribution I would name it 'gl', i.e. all minor case.)
Yes, it's libGL.so in my system and the file was created by mesa. I remember having it as libgl.so in another system.
Have you tried reducing your test case to the point where boost.python isn't part of the setup any more ? It doesn't sound as if your problem is related to neither Python nor boost, in any case.
Yes, apparently I wasn't right about that -lGL causing that, althought it looked like that for the last hour before posting that message. Now it's almost randomly based on my build parameters. I'll post later when I figure things out. Thanks for the reply. -Gazi
Gazihan Alankus wrote:
Stefan Seefeld wrote:
Have you tried reducing your test case to the point where boost.python isn't part of the setup any more ? It doesn't sound as if your problem is related to neither Python nor boost, in any case.
Yes, apparently I wasn't right about that -lGL causing that, althought it looked like that for the last hour before posting that message. Now it's almost randomly based on my build parameters. I'll post later when I figure things out. Thanks for the reply.
My doubts were on that I'm not using bjam and I thought my build parameters could be the cause, but I just disproved it. I edited the sample libs/python/example/quickstart/extending.cpp to write something to std::cerr and compiled it using what bjam -o tells me and it ran fine. When I added -lGL to that and it created the segfault again. So I'm pretty sure that when I link a Boost.Python library to OpenGL, usage of std::cerr gives a segfault. gdb tells me it's being encountered in operator<<(). fprintf(stderr, "something") works fine however. And yes, I have no problems with cerr and OpenGL when Boost.Python is not around. Btw, I recompiled my gcc (libstdc++ and everything), python, boost and mesa in case there was some kind of corruption before. So I'm not sure how to track this down right now. I have no other problem in my system, it's obvious to me that the problem must be in Boost.Python or something related to OpenGL. Since I have no other OpenGL problems, my bets are on Boost.Python. I modified the simple example in libs/python/example/quickstart/extending.cpp of the boost 1.34 source to get this error behavior. Here is the hello class: class hello { public: hello(const std::string& country) { this->country = country; } std::string greet() const { std::cout << "cout" << std::cerr.eof() << " " << std::cerr.fail() << " " << std::cerr.bad() << " " << std::cerr.exceptions() << "\n"; std::cerr << "cerr" << "\n"; return "Hello from " + country; } private: std::string country; }; And this is what I do in python: import extending; a = extending.hello('aoeu'); a.greet() The eof, fail, etc are 0 in both, but I get the segfault when -lGL is there. I found out that I'm actually not the only one: http://mail.datenhain.de/pipermail/libavg-users/2007-March/000085.html http://vdrift.net/Forum/viewtopic.php?p=5128 So, any idea how to track this problem down would be appreciated. I hope this can result in a meaningful bug report in the end. -Gazi
Gazihan Alankus wrote:
I found out that I'm actually not the only one: http://mail.datenhain.de/pipermail/libavg-users/2007-March/000085.html http://vdrift.net/Forum/viewtopic.php?p=5128
Quick addition: Both these other people are using Boost.Python and I couldn't find anyone with the same problem that don't use Boost.Python. I'm having this on Gentoo Linux with a laptop with intel 855 graphics card. Here are versions of everything I tried these with: gcc 4.1.2 python 2.4 and 2.3 mesa 6.5.2 (this is where the opengl library comes from) boost 1.33.1 and 1.34.0 I'm trying to find out what the other people have so we can pin this down. I just filed a bug report: http://svn.boost.org/trac/boost/ticket/1018 -Gazi
Gazihan Alankus wrote:
Gazihan Alankus wrote:
I found out that I'm actually not the only one: http://mail.datenhain.de/pipermail/libavg-users/2007-March/000085.html http://vdrift.net/Forum/viewtopic.php?p=5128
Quick addition: Both these other people are using Boost.Python and I couldn't find anyone with the same problem that don't use Boost.Python. I'm having this on Gentoo Linux with a laptop with intel 855 graphics card. Here are versions of everything I tried these with:
gcc 4.1.2 python 2.4 and 2.3 mesa 6.5.2 (this is where the opengl library comes from) boost 1.33.1 and 1.34.0
I'm trying to find out what the other people have so we can pin this down. I just filed a bug report: http://svn.boost.org/trac/boost/ticket/1018
Can you send a complete (but minimal !) test case exhibiting the problem ? I may have a look into it. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Can you send a complete (but minimal !) test case exhibiting the problem ? I may have a look into it.
Thanks, Stefan
Ok, I'm attaching a very simple source file. Here is how I compiled it along the recommendations of bjam -o: (-g or not didn't matter) "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -fPIC -I"../../../.." -I"/usr/include/python2.4" -c -o "src.o" "src.cpp" "g++" -o "mod.so" -Wl,-h -Wl,mod.so -shared -Wl,--start-group "src.o" /usr/lib/libboost_python.so -L/usr/local/lib -lGL -lutil -lpthread -ldl -Wl,--end-group Here is how I used it: $ python Python 2.4.4 (#1, May 25 2007, 22:22:35) [GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import mod mod.func() cerr!Segmentation fault
Thank you for your interest. If you don't get the same error, I can run any test programs, give you traces or if you prefer I can open up a user account for you in my laptop so that you can ssh in. -Gazi
Gazihan Alankus wrote:
Thank you for your interest. If you don't get the same error, I can run any test programs, give you traces or if you prefer I can open up a user account for you in my laptop so that you can ssh in.
I followed your suggested procedure, and everything seems to run fine. No segfault. I would expect the problem to be somewhere deep down in system libraries and the compiler (toolchain), not directly related to boost or mesa. (Mesa, as a C library, doesn't even know about std::cerr...) (I'm using FC6, with GCC 4.1.1 as system compiler.) Sorry, but I don't think I can help any further at this time. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Gazihan Alankus wrote:
Thank you for your interest. If you don't get the same error, I can run any test programs, give you traces or if you prefer I can open up a user account for you in my laptop so that you can ssh in.
I followed your suggested procedure, and everything seems to run fine. No segfault. I would expect the problem to be somewhere deep down in system libraries and the compiler (toolchain), not directly related to boost or mesa. (Mesa, as a C library, doesn't even know about std::cerr...)
I'm happy to inform everybody that I've solved this, *and* it was related to Mesa. Here is a short overview of what went down: When I dived into gcc's libstdc++-v3 code, I saw that operator<<() was using std::uncaught_exception() to see whether there is an uncought exception around, which was dereferencing what __cxxabiv1::__cxa_get_globals() returns, which was NULL when the library was linked against libGL.so. __cxxabiv1::__cxa_get_globals() had three cases depending on #define's which were all about threading. I didn't know which ones were active, but I pursued all and couldn't end up with anything better than a global variable's pointer being NULL, which didn't make much sense. Maybe it was an extern'ed global variable, but I'm not sure. This was where I stopped a couple of days ago. This morning I wanted to go deep in Mesa, and before I did luckily I saw that Mesa can be compiled with or without Native POSIX Thread Library (NPTL) support and my settings in Gentoo (use flags) included +nptl. I compiled Mesa without nptl support, and voila! cerr works perfectly fine in my Boost.Python library! I'm not sure who to blame:), but I suggest this should be looked into by Boost.Python and Mesa developers. For anyone currently experiencing this strange bug, the solution for the time being is to compile Mesa without NPTL support. -Gazi
Gazihan Alankus wrote:
I'm not sure who to blame:), but I suggest this should be looked into by Boost.Python and Mesa developers. For anyone currently experiencing this strange bug, the solution for the time being is to compile Mesa without NPTL support.
Your description makes it sound as if the error should persist even if you take out all references to boost.python. This seems to be about compatibility between the different runtimes used by Mesa and libstdc++, i.e. in particular whether or not to compile with -pthread. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Your description makes it sound as if the error should persist even if you take out all references to boost.python. This seems to be about compatibility between the different runtimes used by Mesa and libstdc++, i.e. in particular whether or not to compile with -pthread.
You are right, I just proved that it's Python, not Boost.Python. Attached is a simple source extending Python without Boost.Python and that has the same problem with cerr. I guess since all C++ users use Boost.Python to extend, the other two people that saw this error were also using Boost.Python. Thanks for your help. -Gazi
participants (2)
-
Gazihan Alankus -
Stefan Seefeld