Memory corruption in exception translation on OS X 10.7

[Jakob van Santen-2]

Hi all,

I've run across what I think is a strange memory corruption bug affecting C++/Python exception translation on OS X 10.7. A short program that reproduces the bug follows:

#include <boost/python.hpp>

static void
throwme() { throw std::invalid_argument("Bork!"); }

struct Bork {
        void throwy() { throwme(); }
};

#ifdef BORKED
BOOST_PYTHON_MODULE(borked)
{
        boost::python::class_<Bork>("Bork")
            .def("throwy", &Bork::throwy)
        ;
#else
BOOST_PYTHON_MODULE(good)
{
#endif
        boost::python::def("throwy", &throwme);
}

When compiled without the call to class_<Bork>::def(), the exception is caught in handle_exception_impl() and presented to Python as ValueError, as expected:

[jakob@i3-dhcp-172-16-55-176:tmp/pybork]$ python -c "import good; good.throwy()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: Bork!

When compiled with -DBORKED, however, I get a bad free() inside the std::logic_error destructor:

[jakob@i3-dhcp-172-16-55-176:tmp/pybork]$ python -c "import borked; borked.throwy()"
python(77633) malloc: *** error for object 0x7fec22c735a4: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

I first encountered this bug in a private fork of 1.38, but I can reproduce it with a freshly build copy of 1.47. It occurs when building with both llvm-gcc and gcc-gcc, regardless of the optimization level. I built the two test libraries like so:

g++ bork.cxx -g -bundle -flat_namespace -undefined dynamic_lookup -Iboost/include -I/System/Library/Frameworks/Python.framework/Headers/ -Lboost/lib -lboost_python -DBORKED -o borked.so
g++ bork.cxx -g -bundle -flat_namespace -undefined dynamic_lookup -Iboost/include -I/System/Library/Frameworks/Python.framework/Headers/ -Lboost/lib -lboost_python -o good.so

Can anyone reproduce this?

Cheers,
Jakob
_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig

[Niall Douglas]

OS X 10.6 and later have a very aggressive memory allocator in them -
it is superbly quick, but it's still quite young code.

If your BPL example runs under valgrind on Linux fine - and I would
suspect that it does - it'll be a bug in either OS X or Apple's port
of GCC to OS X (which would hardly be the first time).

If it does trip on valgrind on Linux you'll get a much more
enthusiastic response here.

Niall


On 26 Oct 2011 at 21:38, Jakob van Santen wrote:

> Hi all,
>
> I've run across what I think is a strange memory corruption bug affecting C++/Python exception translation on OS X 10.7. A short program that reproduces the bug follows:
>
> #include <boost/python.hpp>
>
> static void
> throwme() { throw std::invalid_argument("Bork!"); }
>
> struct Bork {
>         void throwy() { throwme(); }
> };
>
> #ifdef BORKED
> BOOST_PYTHON_MODULE(borked)
> {
>         boost::python::class_<Bork>("Bork")
>             .def("throwy", &Bork::throwy)
>         ;
> #else
> BOOST_PYTHON_MODULE(good)
> {
> #endif
>         boost::python::def("throwy", &throwme);
> }
>
> When compiled without the call to class_<Bork>::def(), the exception is caught in handle_exception_impl() and presented to Python as ValueError, as expected:
>
> [jakob@i3-dhcp-172-16-55-176:tmp/pybork]$ python -c "import good; good.throwy()"
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ValueError: Bork!
>
> When compiled with -DBORKED, however, I get a bad free() inside the std::logic_error destructor:
>
> [jakob@i3-dhcp-172-16-55-176:tmp/pybork]$ python -c "import borked; borked.throwy()"
> python(77633) malloc: *** error for object 0x7fec22c735a4: pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
>
> I first encountered this bug in a private fork of 1.38, but I can reproduce it with a freshly build copy of 1.47. It occurs when building with both llvm-gcc and gcc-gcc, regardless of the optimization level. I built the two test libraries like so:
>
> g++ bork.cxx -g -bundle -flat_namespace -undefined dynamic_lookup -Iboost/include -I/System/Library/Frameworks/Python.framework/Headers/ -Lboost/lib -lboost_python -DBORKED -o borked.so
> g++ bork.cxx -g -bundle -flat_namespace -undefined dynamic_lookup -Iboost/include -I/System/Library/Frameworks/Python.framework/Headers/ -Lboost/lib -lboost_python -o good.so
>
> Can anyone reproduce this?
>
> Cheers,
> Jakob
> _______________________________________________
> Cplusplus-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/cplusplus-sig

--
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no:
472909.



_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig