boost::python with virtual inheritance and g++ c++0x/11 (testcase attached)
Moin folks, I recently upgraded to boost::python 1.48 and g++ 4.7 (fedora 17). This broke a project of mine as it crashes when passing an object with virtual inheritance from python back to C++ (e.g. during a method call). A minimal test case is attached. After nearly an hour of debugging in a single gdb session, I found that the value in the PyObject* itself does not change. When the value was first wrapped into a PyObject*, I noted down the address of that and did trial&error dereferencing until I was able to get the actual wrapped object: (gdb) disp (((PyUni::X11Window**)((long*)raw_result)[5])[2]) in the context of /usr/include/boost/python/object/make_instance.hpp:49 (PyUni::X11Window* being the object to be wrapped) The offset 5 was found by inspecting python's object.h, the 2 by guessing (at [5] we find an auto_ptr instance). I added a watchpoint to gdb on that location which did not trigger. Also, after the segfault, I inspected the same adress by replacing raw_result with the appropriate pointer (I noted down the address raw_result was pointing to before continuing from make_instance.hpp:49). Then I was able to reproduce the problem and pin it down to virtual inheritance and g++ -std=c++0x (c++11 does the same), so I built the attached test case. The archive contains (no tarbomb) a single cpp file and two methods to build it. For those for whom it works, there is the simple.Makefile, which relies on hardcoded paths. A CMakeLists.txt is provided for those with cmake and for whom the simple Makefile does not work. Another quick test with boost 1.49 did not fix the issue. -- Jonas
On 14 May 2012 at 9:48, Jonas Wielicki wrote:
I recently upgraded to boost::python 1.48 and g++ 4.7 (fedora 17). This broke a project of mine as it crashes when passing an object with virtual inheritance from python back to C++ (e.g. during a method call). A minimal test case is attached.
I would be almost certain that your bug stems from changes to GCC, not changes to BPL. Generally speaking GCC bugs fix themselves over time, so you can revert temporarily to an older GCC. Bugs in GCC are common enough that if my code fails, I first think it's GCC's fault :) Try an older GCC. Also, try Clang. Clang seems to generate better debug info for templates anyway. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 14/05/12 12:37, Niall Douglas wrote:
I would be almost certain that your bug stems from changes to GCC, not changes to BPL. By now, this is also my suspect. Mainly, because it should be just one function call between the value being correct and being wrong, while it is only passed as a by-value argument.
Generally speaking GCC bugs fix themselves over time, so you can revert temporarily to an older GCC. Bugs in GCC are common enough that if my code fails, I first think it's GCC's fault :) Hm. GCC updates are rather rare though I think? Also its kinda inconvienient to use a non-distribution gcc version. Do you recommend to submit a bug report to the gcc folks on that one?
Also, try Clang. Clang seems to generate better debug info for templates anyway. I'll have a look, thanks.
-- Jonas
On 14 May 2012 at 12:53, Jonas Wielicki wrote:
Generally speaking GCC bugs fix themselves over time, so you can revert temporarily to an older GCC. Bugs in GCC are common enough that if my code fails, I first think it's GCC's fault :) Hm. GCC updates are rather rare though I think?
Not at all - GCC has a very rapid release cycle compared to most other C++ compilers. Most compilers are only released every two or even four years.
Also its kinda inconvienient to use a non-distribution gcc version.
Most distros bundle multiple versions of gcc due to this exact problem with frequent bugs. Debian, at least, usually has the previous version and for many years also had the latest from the 3.x and indeed 2.x series. Simply have your build chain wire in a non-default compiler by excluding from a list of known broken gcc's. It's what my build system does.
Do you recommend to submit a bug report to the gcc folks on that one?
I personally do. But getting a bug accepted by gcc isn't easy. You may need to be prepared for them to be a bit caustic to you. A very small testcase is easiest. They don't like testcases bringing in external libraries such as boost one bit. So be prepared to be aggressive if needs be.
Also, try Clang. Clang seems to generate better debug info for templates anyway. I'll have a look, thanks.
Personally speaking now BSD has switched to Clang I think GCC is living on borrowed time. Clang can already build 90%+ of all Debian, and it won't be long before it's 100%. At that point there is no longer any good reason to continue using GCC except for the languages LLVM doesn't support. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 05/14/2012 01:33 PM, Niall Douglas wrote:
Most distros bundle multiple versions of gcc due to this exact problem with frequent bugs. Debian, at least, usually has the previous version and for many years also had the latest from the 3.x and indeed 2.x series. Well, Fedora doesn't. They only ship a 3.4 series compiler as an alternative (maybe to build qt3 apps or something?). But actually I like -std=C++0x, you know.
Simply have your build chain wire in a non-default compiler by excluding from a list of known broken gcc's. It's what my build system does. Hm. How did you implement that? I mean, does the build chain build its own gcc if neccessary and install it to a well-defined path in the user's home directory?
On 14 May 2012 at 12:53, Jonas Wielicki wrote:
Do you recommend to submit a bug report to the gcc folks on that one?
I personally do. But getting a bug accepted by gcc isn't easy. You may need to be prepared for them to be a bit caustic to you. I guessed so. Have to remind the discussion between linux kernel folks and gcc people over whether its a bug in the gcc when a null pointer derefenciation in the kernel opens a security hole ;).
A very small testcase is easiest. They don't like testcases bringing in external libraries such as boost one bit. So be prepared to be aggressive if needs be. Hm. I'm afraid that this bug is not easy to separate in a small testcase, because if it was evident, the fedora folks would've (a) filed a bug at the gcc or (b) put in a patch themselves but definetly (c) not shipped that compiler.
Also, try Clang. Clang seems to generate better debug info for templates anyway. I'll have a look, thanks. Clang doesn't compile boost python 1.49 at all. Sadly.
I guess I'll have to temporarily build a 4.6 gcc for myself, until that issue is fixed. -- Jonas
On 14 May 2012 at 15:11, Jonas Wielicki wrote:
On 05/14/2012 01:33 PM, Niall Douglas wrote:
Most distros bundle multiple versions of gcc due to this exact problem with frequent bugs. Debian, at least, usually has the previous version and for many years also had the latest from the 3.x and indeed 2.x series. Well, Fedora doesn't. They only ship a 3.4 series compiler as an alternative (maybe to build qt3 apps or something?). But actually I like -std=C++0x, you know.
Haven't touched Fedora in a decade I'm afraid. I should clarify my earlier statement: Debian doesn't necessarily install by default multiple versions of compilers, rather they're in the repos available as package dependencies. Surely Fedora is the same?
Simply have your build chain wire in a non-default compiler by excluding from a list of known broken gcc's. It's what my build system does. Hm. How did you implement that? I mean, does the build chain build its own gcc if neccessary and install it to a well-defined path in the user's home directory?
Ah, my build system has been scons for years now. As that's really python, it's trivial to scan /usr/bin for anything which can compile and invoke each with --version or take a guess from their filename. My build system simply warns with big letters if the only compiler available is known to be broken and suggests you should get a different one, but one can force proceed if you wish.
A very small testcase is easiest. They don't like testcases bringing in external libraries such as boost one bit. So be prepared to be aggressive if needs be. Hm. I'm afraid that this bug is not easy to separate in a small testcase, because if it was evident, the fedora folks would've (a) filed a bug at the gcc or (b) put in a patch themselves but definetly (c) not shipped that compiler.
Indeed. My experience has been trying when reporting complex metaprogramming bugs in GCC. They say things like "we regularly test against Boost and the compiler passes all its regression tests, therefore the bug can't be in our compiler". Understandable, but frustrating.
Also, try Clang. Clang seems to generate better debug info for templates anyway. I'll have a look, thanks. Clang doesn't compile boost python 1.49 at all. Sadly.
I am deeply surprised due to http://blog.llvm.org/2010/05/clang-builds-boost.html. http://www.boost.org/development/tests/release/developer/python.html reports Clang to be no worse than MSVC, and much better than GCC 4.2. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 05/14/2012 04:05 PM, Niall Douglas wrote:
Debian doesn't necessarily install by default multiple versions of compilers, rather they're in the repos available as package dependencies. Surely Fedora is the same? Nope, I was talking about the repositories.
Ah, my build system has been scons for years now. As that's really python, it's trivial to scan /usr/bin for anything which can compile and invoke each with --version or take a guess from their filename. Okay, we're on cmake here. I really should take a look at scons. I mean, its python.
Indeed. My experience has been trying when reporting complex metaprogramming bugs in GCC. They say things like "we regularly test against Boost and the compiler passes all its regression tests, therefore the bug can't be in our compiler". Understandable, but frustrating. This sounds a bit like one should add that testcase to the regression testsuite in boost to get a gcc bug fixed, eh? ;).
Clang doesn't compile boost python 1.49 at all. Sadly. Sure, you're right. Sorry, it was my fault in reading clang's error messages. It chockes on the c++ stl bits, not on boost, but they're included from boost, so the first thing I read was “boost”. Well, I cannot tell if it would choke on boost too, but I guess your testing setup is more sane than mine (at least it's not holding a spatula).
-- Jonas
Clang doesn't compile boost python 1.49 at all. Sadly. Sure, you're right. Sorry, it was my fault in reading clang's error messages. It chockes on the c++ stl bits, not on boost, but they're included from boost, so the first thing I read was “boost”. Well, I cannot tell if it would choke on boost too, but I guess your testing setup is more sane than mine (at least it's not holding a spatula).
That is a typical error with clang, which is typically solved by point 6 here: http://clang.llvm.org/get_started.html To use that advice you have to build your own clang though (not difficult at all). Clang by default uses gcc's system libraries to be binary compatible to the rest of Linux. The difficult part is that this has to be adjusted for every distribution and every gcc version. I experienced problems with this for multiple distributions. -Holger
On 14 May 2012 at 16:22, Jonas Wielicki wrote:
Debian doesn't necessarily install by default multiple versions of compilers, rather they're in the repos available as package dependencies. Surely Fedora is the same? Nope, I was talking about the repositories.
Well, well. Didn't think that likely.
Ah, my build system has been scons for years now. As that's really python, it's trivial to scan /usr/bin for anything which can compile and invoke each with --version or take a guess from their filename. Okay, we're on cmake here. I really should take a look at scons. I mean, its python.
scons suffers from an O(N^2) complexity with source file count. Other than that it's great ...
Clang doesn't compile boost python 1.49 at all. Sadly. Sure, you're right. Sorry, it was my fault in reading clang's error messages. It chockes on the c++ stl bits, not on boost, but they're included from boost, so the first thing I read was "boost". Well, I cannot tell if it would choke on boost too, but I guess your testing setup is more sane than mine (at least it's not holding a spatula).
It chokes on the GCC STL sure. Not so much its own STL. I am out of date here though, it's been some years since I debugged C++ on POSIX as recently cygwin has spat out fully working binaries on Windows after being debugged in MSVC, so no need to go native POSIX recently. I'm actually starting a new job with a well known multinational this autumn where I'll be developing using C++ on POSIX exclusively. That should bring me very much up to date. My first personal order of business, coincidentally, will be porting their build environment from GCC to Clang to gain some sanity for the metaprogramming that comes next. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Okay, due to the other thread over there, I came back to this topic even after I reverted to fedora 16 due to some other issues (they actually removed ddate. Still cannot believe!) I am working on a bugreport for the gcc folks right now, and during that I came across the release notes for gcc 4.7[1] and found the following. However, it seems that the actual problematic code is located in the libboost itself. I am wondering how to report that properly. The gcc folks want the -save-temps flag, but I really do not look through the boost build system enough to know which file is to be built with the correct option to get the result the gcc folks want. Any pointers here? Its somewhere about inheritance.cpp:405. -- Jonas
On 19.05.2012 12:01, Jonas Wielicki wrote:
I am working on a bugreport for the gcc folks right now, and during that I came across the release notes for gcc 4.7[1] and found the following.
missed reference, sorry: [1] http://gcc.gnu.org/gcc-4.7/changes.html#cxx -- Jonas
On 19 May 2012 at 12:01, Jonas Wielicki wrote:
I am working on a bugreport for the gcc folks right now, and during that I came across the release notes for gcc 4.7[1] and found the following.
That's a huge amount of new compliance with C++11. No wonder there are bugs.
However, it seems that the actual problematic code is located in the libboost itself. I am wondering how to report that properly. The gcc folks want the -save-temps flag, but I really do not look through the boost build system enough to know which file is to be built with the correct option to get the result the gcc folks want. Any pointers here?
Its somewhere about inheritance.cpp:405.
1. Does the bug occur in non-optimised as well as optimised builds? 2. Does the bug occur when C++11 is turned off? 3. What are your -fvisibility settings? 4. Does the bug occur when inlining is force switched off? 5. Are you using precompiled headers? If so, does the bug occur when you turn those off? 6. Can you spot where in the assembly it's making a pointer dereferencing mistake? I would be surprised if inheritance.cpp actually contains the offending code. More likely it's in the template headers, and therefore the compiler chooses one of the copies assembled in each compiland to go into the final binary. If that's the case, which file you choose for save temps is immaterial. If you're *really* unlucky, the bug is that different assembler is being generated in different compilands and the fact you're seeing a problem is due to sheer chance because of the stochastic choice the linker made :) Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 21.05.2012 17:55, Niall Douglas wrote:
1. Does the bug occur in non-optimised as well as optimised builds? It does.
2. Does the bug occur when C++11 is turned off? It does not.
3. What are your -fvisibility settings? Unchanged to default... Does this help any? Can I find out whats default on my machine if its configurable at gcc-build-time?
4. Does the bug occur when inlining is force switched off? Yes.
5. Are you using precompiled headers? If so, does the bug occur when you turn those off? I think I am not. I would know if I did, wouldn't I? At least I can browse through the header sources at /usr/include/boost/..
6. Can you spot where in the assembly it's making a pointer dereferencing mistake? That is in the template, but the pointer value changes inside code which is compiled in the boost library.
Within the function defined around inheritance.cpp:392, the value of the object pointer (I think it's called p) changes. I was yet unable to find the specific point where the value is changed, because a lot of subfunctions get called in there and, to be honest, I'm not that familiar with gcc yet. Also it seems as maybe the wrong value is only passed, while it is still intact on stack (gcc at least shows me differing values for the two stackframes), but that might be due to debug data or gcc magic?
If you're *really* unlucky, the bug is that different assembler is being generated in different compilands and the fact you're seeing a problem is due to sheer chance because of the stochastic choice the linker made :) Actually, the problem is deterministic. I compiled the binary many times now and with gcc 4.7 I always get the segfault, at the same instruction, with the same surroundings (changed pointer value from one stack frame to the other).
-- Jonas
Hi, I will use a shared pointer to my Python script I expose my class : class_<handler::Target, boost::shared_ptr<handler::Target> >("Target") .def("getRadius", &handler::Target::getRadius) .def("setRadius", &handler::Target::setRadius) .def("setPosition", &handler::Target::setPosition) ; and I use a method "getTestTarget" who return a shared pointer on my member variable vgd::Shp<vgSofa::handler::Target> InterfaceScriptBoost::getTestTarget() { return UlisBoost::m_testTarget; } And the exposition of is methode is : def("getTestTarget", &dtUlis::InterfaceScriptBoost::getTestTarget, python::return_value_policy<python::reference_existing_object>()); I want to know if it is true ? Any help would be appreciated, thank you
On May 22, 2012 8:38 AM, "Yoann Chaumy" <spartan811@hotmail.com> wrote:
Hi, I will use a shared pointer to my Python script
I expose my class :
class_<handler::Target, boost::shared_ptr<handler::Target> >("Target") .def("getRadius", &handler::Target::getRadius) .def("setRadius", &handler::Target::setRadius) .def("setPosition", &handler::Target::setPosition) ;
and I use a method "getTestTarget" who return a shared pointer on my
member variable
vgd::Shp<vgSofa::handler::Target> InterfaceScriptBoost::getTestTarget() { return UlisBoost::m_testTarget; }
And the exposition of is methode is :
def("getTestTarget", &dtUlis::InterfaceScriptBoost::getTestTarget,
python::return_value_policy<python::reference_existing_object>());
I want to know if it is true ?
Any help would be appreciated, thank you
If you are returning a smart pointer, there is no need to use a call policy like return_value_policy<...>. However, you have wrapped the class with boost::shared_ptr and are returning a different kind of shared pointer. That won't work. It's easier if you can just use boost::shared_ptr everywhere, but it is also possible to set up conversions for a custom smart pointer. HTH Jim
If you are returning a smart pointer, there is no need to use a call policy like return_value_policy<...>. However, you have wrapped the class with boost::shared_ptr and are returning a different kind of shared pointer. That won't work. It's easier if you can just use boost::shared_ptr everywhere, but it is also possible to set up conversions for a custom smart pointer. Ok thank you. But I have a error, when I try to expose my class : Assertion failed! Program: ... File: libs\python\src\converter\registry.cpp Line: 207 Expression: slot->m_to_python == 0 I am using MS Visual Express 2010
On 21 May 2012 at 18:43, Jonas Wielicki wrote:
On 21.05.2012 17:55, Niall Douglas wrote:
1. Does the bug occur in non-optimised as well as optimised builds? It does.
Joy.
2. Does the bug occur when C++11 is turned off? It does not.
Not so much joy. It could, technically speaking, be a misinterpretation of C++03 by either BPL or GCC. Still, at least it narrows things down.
5. Are you using precompiled headers? If so, does the bug occur when you turn those off? I think I am not. I would know if I did, wouldn't I? At least I can browse through the header sources at /usr/include/boost/..
Precompiled headers on GCC are basically a dump of state just after processing the headers. As a result, the file is huge. That might help you find out if they're on. I believe bjam defaults them to off.
6. Can you spot where in the assembly it's making a pointer dereferencing mistake? That is in the template, but the pointer value changes inside code which is compiled in the boost library.
Are you saying that the *offset* changes inside the code? So, class A has vtable at this[-8]. I access a->foo() which indexes this[-8] by 0x16 in the headers. But inside the compiland, a->foo() indexes this[-8] by 0x20, which is wrong.
Within the function defined around inheritance.cpp:392, the value of the object pointer (I think it's called p) changes. I was yet unable to find the specific point where the value is changed, because a lot of subfunctions get called in there and, to be honest, I'm not that familiar with gcc yet. Also it seems as maybe the wrong value is only passed, while it is still intact on stack (gcc at least shows me differing values for the two stackframes), but that might be due to debug data or gcc magic?
Yeah the GCC ABI is a bit fusty. Got a lot better in 3.2 onwards though. You might find http://sourcery.mentor.com/public/cxx-abi/cxx-vtable-ex.html useful as a reference for the C++03 ABI. Of course, almost certainly the bug you're seeing is related to the ABI changes they're making for C++11, of which there are quite a few. If I had to take a guess, your problems might have something to do with fixing bugs in decltype support e.g. one of the changelog items in 4.7 is "The representation of C++ virtual thunks and aliases (both implicit and defined via the alias attribute) has been re-engineered. Aliases no longer pose optimization barriers and calls to an alias can be inlined and otherwise optimized." BTW - can I just clarify you ARE compiling the entire of BPL using C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but not the other way round), but I can see nests of vipers in it.
If you're *really* unlucky, the bug is that different assembler is being generated in different compilands and the fact you're seeing a problem is due to sheer chance because of the stochastic choice the linker made :) Actually, the problem is deterministic. I compiled the binary many times now and with gcc 4.7 I always get the segfault, at the same instruction, with the same surroundings (changed pointer value from one stack frame to the other).
Given the information so far, you have an excellent chance of getting it fixed. Another thought - I once persuaded the GCC devs to accept a bug when I demonstrated that ICC (Intel's compiler) got it right. ICC is free on Linux, so that might be worth a shot too. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
When I had this problem I had not built BPL using C++11, how would I instruct bjam to use gcc at a specific location and with the -std=c++0x flag? -- Gabe Rives-Corbett Cell: (805) 570-8395 On Tuesday, May 22, 2012 at 10:43 AM, Niall Douglas wrote:
On 21 May 2012 at 18:43, Jonas Wielicki wrote:
On 21.05.2012 17:55, Niall Douglas wrote:
1. Does the bug occur in non-optimised as well as optimised builds?
It does.
Joy.
2. Does the bug occur when C++11 is turned off? It does not.
Not so much joy. It could, technically speaking, be a misinterpretation of C++03 by either BPL or GCC. Still, at least it narrows things down.
5. Are you using precompiled headers? If so, does the bug occur when you turn those off?
I think I am not. I would know if I did, wouldn't I? At least I can browse through the header sources at /usr/include/boost/..
Precompiled headers on GCC are basically a dump of state just after processing the headers. As a result, the file is huge. That might help you find out if they're on. I believe bjam defaults them to off.
6. Can you spot where in the assembly it's making a pointer dereferencing mistake?
That is in the template, but the pointer value changes inside code which is compiled in the boost library.
Are you saying that the *offset* changes inside the code?
So, class A has vtable at this[-8].
I access a->foo() which indexes this[-8] by 0x16 in the headers.
But inside the compiland, a->foo() indexes this[-8] by 0x20, which is wrong.
Within the function defined around inheritance.cpp:392, the value of the object pointer (I think it's called p) changes. I was yet unable to find the specific point where the value is changed, because a lot of subfunctions get called in there and, to be honest, I'm not that familiar with gcc yet. Also it seems as maybe the wrong value is only passed, while it is still intact on stack (gcc at least shows me differing values for the two stackframes), but that might be due to debug data or gcc magic?
Yeah the GCC ABI is a bit fusty. Got a lot better in 3.2 onwards though. You might find http://sourcery.mentor.com/public/cxx-abi/cxx-vtable-ex.html useful as a reference for the C++03 ABI.
Of course, almost certainly the bug you're seeing is related to the ABI changes they're making for C++11, of which there are quite a few. If I had to take a guess, your problems might have something to do with fixing bugs in decltype support e.g. one of the changelog items in 4.7 is "The representation of C++ virtual thunks and aliases (both implicit and defined via the alias attribute) has been re-engineered. Aliases no longer pose optimization barriers and calls to an alias can be inlined and otherwise optimized."
BTW - can I just clarify you ARE compiling the entire of BPL using C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but not the other way round), but I can see nests of vipers in it.
If you're *really* unlucky, the bug is that different assembler is being generated in different compilands and the fact you're seeing a problem is due to sheer chance because of the stochastic choice the linker made :)
Actually, the problem is deterministic. I compiled the binary many times now and with gcc 4.7 I always get the segfault, at the same instruction, with the same surroundings (changed pointer value from one stack frame to the other).
Given the information so far, you have an excellent chance of getting it fixed.
Another thought - I once persuaded the GCC devs to accept a bug when I demonstrated that ICC (Intel's compiler) got it right. ICC is free on Linux, so that might be worth a shot too.
Niall
-- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org (mailto:Cplusplus-sig@python.org) http://mail.python.org/mailman/listinfo/cplusplus-sig
On 22.05.2012 18:07, Gabe Rives-Corbett wrote:
how would I instruct bjam to use gcc at a specific location and with the -std=c++0x flag?
I found that the following works if you replace the existing section of the project-config.jam file in the boost source tarball:
snip # Compiler configuration. This definition will be used unless # you already have defined some toolsets in your user-config.jam # file. if ! gcc in [ feature.values <toolset> ] { using gcc : : : <compileflags>-std=c++11 ; } <<< snip
Verify that it works for you by calling b2 or bjam with -d2. This will print you the g++ calls to the terminal. Check that the -std=c++11 flag is present there. -- Jonas
On 22.05.2012 16:43, Niall Douglas wrote:
Precompiled headers on GCC are basically a dump of state just after processing the headers. As a result, the file is huge. That might help you find out if they're on. I believe bjam defaults them to off. Well, in that case I'm not using them. They would've sprung into my eyes if they're located in the default -I-paths (which I assume).
6. Can you spot where in the assembly it's making a pointer dereferencing mistake? That is in the template, but the pointer value changes inside code which is compiled in the boost library.
Are you saying that the *offset* changes inside the code? Hm, I was unclear I guess. I'm going to paste some gdb bt output:
BTW - can I just clarify you ARE compiling the entire of BPL using C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but not the other way round), but I can see nests of vipers in it. Ehm, I guess not, so I just downloaded and rebuilt boost 1.48 in the virtual machine (no fun) with -std=c++11 flag (I added this in the
Given the information so far, you have an excellent chance of getting it fixed. Okay, so I'm taking you suggest I submit both compilation attempts (inheritance.cpp and crashtest.cpp) with -save-temps for comparision to
#0 0x0000000000405af7 in boost::python::objects::polymorphic_id_generator<Foo>::execute (p_=0x40a268) at /usr/include/boost/python/object/inheritance.hpp:43 #1 0x00007ffff7dcb684 in boost::(anonymous namespace)::convert_type (p= 0x666db0, src_t=..., dst_t=..., polymorphic=true) at /usr/src/debug/boost_1_48_0/libs/python/src/object/inheritance.cpp:405 Here we see that to convert_type, p=0x666db0 has been passed, while 0x40a268 arrived in execute. While the first value is a valid pointer to a Foo instance, 0x40a268 is anything but that (actually I did not find out yet what was going on there). However, p is just passed on to execute without modification (as far as I can see in the code). project-options.jam file at the using line; running ./b2 -d2 showed me that the flag was passed to the gcc too). Still, the crash occurs at the same place. the gcc devs? Of course with all the information I gathered so far. -- Jonas
On 22 May 2012 at 18:33, Jonas Wielicki wrote:
BTW - can I just clarify you ARE compiling the entire of BPL using C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but not the other way round), but I can see nests of vipers in it. Ehm, I guess not, so I just downloaded and rebuilt boost 1.48 in the virtual machine (no fun) with -std=c++11 flag (I added this in the project-options.jam file at the using line; running ./b2 -d2 showed me that the flag was passed to the gcc too). Still, the crash occurs at the same place.
Ok.
Given the information so far, you have an excellent chance of getting it fixed. Okay, so I'm taking you suggest I submit both compilation attempts (inheritance.cpp and crashtest.cpp) with -save-temps for comparision to the gcc devs? Of course with all the information I gathered so far.
Include the answers to the questions I asked about force inlining, is BPL compiled as c++11, the problem doesn't show in c++03 etc. It shows you've been thorough. Do post the bugzilla link here, I'd like to CC into it. Thanks, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 22.05.2012 19:05, Niall Douglas wrote:
Do post the bugzilla link here, I'd like to CC into it. There you go: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
I hope they won't murder me for the .gz ;). -- Jonas
participants (6)
-
Gabe Rives-Corbett -
Holger Brandsmeier -
Jim Bosch -
Jonas Wielicki -
Niall Douglas -
Yoann Chaumy