Hi, This crash has always occurred, even since 1.34.1. It's now reproducible in 1.35. I use the following command line to build boost in such a way that Boost.Python links against the debug python libraries: bjam --toolset=msvc --layout=system link=shared threading=multi variant=debug python-debugging=on stage Note that Visual Studio 2008 is the only MSVC compiler installed on my system. I'm using Python 2.5.2. Any time I call into a Boost.Python function I get an access violation when writing to location 0x00000000. Note that I have been able to get crashes when calling the initMyInterface() function for BOOST_PYTHON_MODULE(MyInterface), I also have gotten this crash when calling into boost::list::insert(). I have no idea what the issue could be. Note that when I built Boost.Python (debug) using the visual studio project before it was removed in 1.35, it worked perfectly. Any help is greatly appreciated since this is a complete blocker issue for me.
It seems like the command line I was using earlier isn't working correctly. For some reason boost_python-mt-gyd is linking against BOTH the release AND debug versions of the python library. The only way around this is to modify the user-config.bjam file, as below: using python : 2.5 : # cmd-or-prefix : c:\\rocket_support\\vc9\\include : c:\\rocket_support\\vc9\\lib : <python-debugging>on ; On Tue, Apr 8, 2008 at 1:52 PM, Robert Dailey <rcdailey@gmail.com> wrote:
Hi,
This crash has always occurred, even since 1.34.1. It's now reproducible in 1.35. I use the following command line to build boost in such a way that Boost.Python links against the debug python libraries:
bjam --toolset=msvc --layout=system link=shared threading=multi variant=debug python-debugging=on stage
Note that Visual Studio 2008 is the only MSVC compiler installed on my system. I'm using Python 2.5.2. Any time I call into a Boost.Python function I get an access violation when writing to location 0x00000000. Note that I have been able to get crashes when calling the initMyInterface() function for BOOST_PYTHON_MODULE(MyInterface), I also have gotten this crash when calling into boost::list::insert().
I have no idea what the issue could be. Note that when I built Boost.Python (debug) using the visual studio project before it was removed in 1.35, it worked perfectly. Any help is greatly appreciated since this is a complete blocker issue for me.
Any word on if this is a bug? Can it be fixed? On Tue, Apr 8, 2008 at 5:16 PM, Robert Dailey <rcdailey@gmail.com> wrote:
It seems like the command line I was using earlier isn't working correctly. For some reason boost_python-mt-gyd is linking against BOTH the release AND debug versions of the python library. The only way around this is to modify the user-config.bjam file, as below:
using python : 2.5 : # cmd-or-prefix : c:\\rocket_support\\vc9\\include : c:\\rocket_support\\vc9\\lib : <python-debugging>on ;
On Tue, Apr 8, 2008 at 1:52 PM, Robert Dailey <rcdailey@gmail.com> wrote:
Hi,
This crash has always occurred, even since 1.34.1. It's now reproducible in 1.35. I use the following command line to build boost in such a way that Boost.Python links against the debug python libraries:
bjam --toolset=msvc --layout=system link=shared threading=multi variant=debug python-debugging=on stage
Note that Visual Studio 2008 is the only MSVC compiler installed on my system. I'm using Python 2.5.2. Any time I call into a Boost.Python function I get an access violation when writing to location 0x00000000. Note that I have been able to get crashes when calling the initMyInterface() function for BOOST_PYTHON_MODULE(MyInterface), I also have gotten this crash when calling into boost::list::insert().
I have no idea what the issue could be. Note that when I built Boost.Python (debug) using the visual studio project before it was removed in 1.35, it worked perfectly. Any help is greatly appreciated since this is a complete blocker issue for me.
*bump* Sorry if I seem impatient, but why has no one responded? On Wed, Apr 9, 2008 at 11:34 AM, Robert Dailey <rcdailey@gmail.com> wrote:
Any word on if this is a bug? Can it be fixed?
On Tue, Apr 8, 2008 at 5:16 PM, Robert Dailey <rcdailey@gmail.com> wrote:
It seems like the command line I was using earlier isn't working correctly. For some reason boost_python-mt-gyd is linking against BOTH the release AND debug versions of the python library. The only way around this is to modify the user-config.bjam file, as below:
using python : 2.5 : # cmd-or-prefix : c:\\rocket_support\\vc9\\include : c:\\rocket_support\\vc9\\lib : <python-debugging>on ;
On Tue, Apr 8, 2008 at 1:52 PM, Robert Dailey <rcdailey@gmail.com> wrote:
Hi,
This crash has always occurred, even since 1.34.1. It's now reproducible in 1.35. I use the following command line to build boost in such a way that Boost.Python links against the debug python libraries:
bjam --toolset=msvc --layout=system link=shared threading=multi variant=debug python-debugging=on stage
Note that Visual Studio 2008 is the only MSVC compiler installed on my system. I'm using Python 2.5.2. Any time I call into a Boost.Python function I get an access violation when writing to location 0x00000000. Note that I have been able to get crashes when calling the initMyInterface() function for BOOST_PYTHON_MODULE(MyInterface), I also have gotten this crash when calling into boost::list::insert().
I have no idea what the issue could be. Note that when I built Boost.Python (debug) using the visual studio project before it was removed in 1.35, it worked perfectly. Any help is greatly appreciated since this is a complete blocker issue for me.
participants (1)
-
Robert Dailey