[C++-sig] Multiple calls to bp::detail::init_module() causing conflicts?

[Austin Bingham]

I've attached a patch that implements what I think is a reasonable fix
for the problem I found. Essentially, it implements
BOOST_PYTHON_MODULE under python3 such that each invocation of the
macro creates a new static PyModuleDef. I also reimplemented
bp::detail::init_module for the python3 case to take a PyModuleDef
parameter rather than a name.

As far as I can tell, these changes work well. I ran bjam in
"libs/python/test" and didn't see any failures...I saw a lot of lines
saying "**passed**", but none saying "**failed**", so I assume things
are ok. If there are more tests that need to be run, please let me
know, and tell me how to run them.

I also tested the changes against a project which was manifesting the
original problem I described, and the problems went away. That is,
with the changes in this patch, my extension modules all have the
correct "__name__" now.

Austin

On Mon, Dec 20, 2010 at 4:04 PM, Austin Bingham
<austin.bingham at gmail.com> wrote:
> I'm in the process of upgrading my project to boost-1.45.0 and
> python3, and I started seeing strange problems with some of my
> boost.python-based extension modules. Essentially, some of my modules
> are reporting the wrong module name, i.e. if I
> "print(module_object.__name__)", I get the wrong value. I threw this
> into gdb, and it looks like the problem might have to do with the
> implementation of bp::detail::init_module().
>
> I ran python under gdb, but a breakpoint on init_module(), and
> imported the modules with which I'm seeing problems. The first call to
> init_module() initializes the static PyModuleDef struct "moduledef"
> properly. However, the second call shows that the "m_name" field it
> left as-is from the first call (since the object is static); I would
> have expected that it needs to be updated with the new module name.
> This stale (I think) module def is then used for the rest of the
> initialization, and I'm guessing that this is the cause of the
> problems I'm seeing. Certainly, it seems that the name of the first
> module imported seems to be getting used as the name of the second
> module.
>
> I only noticed this problem when I tried to pickle some of the types
> exposed by my module. The pickle module in python3 complained that it
> didn't know anything about the broken modules I was getting.
>
> Is this a bug in boost.python? I plan to write a small patch tomorrow
> to set the m_name field in init_module(), so maybe this will fix the
> problem.
>
> If this isn't a boost.python bug, does anyone have any idea what might
> be going wrong? And how is it correct that the static moduledef is
> reused without updating its name?
>
> Thanks,
> Austin
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python3_bp_module.diff
Type: text/x-diff
Size: 5334 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20101225/9bab7240/attachment.diff>