Subject: Re: [boost] boost.python problem in release branch (GSoc work)
From: Haoyu Bai (divinekid_at_[hidden])
Date: 2009-11-07 07:59:17
On Sat, Nov 7, 2009 at 2:44 PM, Ralf W. Grosse-Kunstleve <rwgk_at_[hidden]> wrote:
> I just found out that two boost.python tests (svn trunk and release) are not valgrind clean. I fear this could be a serious problem, although I've not seen actual failures apart from the valgrind diagnostics. What I know at the moment is:
> produce valgrind errors with trunk revision 56305 but not 56304 (fedora 8 64-bit).
> The critical revision 56305 is:
> Merged 2009 GSoC work from sandbox-branches/bhy/py3k branch back into trunk.
> It is merged into the release branch already.
> Unfortunately, without revision 56305 boost.python does not work with Python 2.6.3 and 2.6.4, i.e. backing out rev. 56305 and some followup revisions would only replace one problem with another.
> How far along is the 1.41 release? Is there a chance it could be delayed for a few days?
> P.S.: I'll add this issue to the tracker when I get a chance (hopefully tomorrow).
I checked with valgrind on trunk, but didn't see any issue reported by
valgrind. Maybe because I'm running on 32-bit Linux and Python 2.6 and
3.1? I have run valgrind in this way: (With PyObject_Free and
PyObject_Realloc additionally suppressed)
$ valgrind --suppressions=valgrind-python.supp python data_members.py
==15636== Memcheck, a memory error detector
==15636== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==15636== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==15636== Command: python data_members.py
==15636== HEAP SUMMARY:
==15636== in use at exit: 1,723,204 bytes in 823 blocks
==15636== total heap usage: 11,524 allocs, 10,701 frees, 10,587,228
==15636== LEAK SUMMARY:
==15636== definitely lost: 0 bytes in 0 blocks
==15636== indirectly lost: 0 bytes in 0 blocks
==15636== possibly lost: 16,391 bytes in 35 blocks
==15636== still reachable: 1,706,813 bytes in 788 blocks
==15636== suppressed: 0 bytes in 0 blocks
==15636== Rerun with --leak-check=full to see details of leaked memory
==15636== For counts of detected and suppressed errors, rerun with: -v
==15636== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1513 from 89)
Which Python version you are running?
Anyway, since the problem occur in properties.py and data_members.py,
I think it maybe related to this part of the changeset:
But I don't see any suspicious at here. Any idea?
-- Haoyu BAI School of Computing, National University of Singapore.