<div class="gmail_quote">On Fri, Aug 31, 2012 at 5:35 PM, Ondřej Čertík <span dir="ltr"><<a href="mailto:ondrej.certik@gmail.com" target="_blank">ondrej.certik@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Dag,<br>
<div><div class="h5"><br>
On Fri, Aug 31, 2012 at 4:22 AM, Dag Sverre Seljebotn<br>
<<a href="mailto:d.s.seljebotn@astro.uio.no">d.s.seljebotn@astro.uio.no</a>> wrote:<br>
> On 08/31/2012 09:03 AM, Ondřej Čertík wrote:<br>
>> Hi,<br>
>><br>
>> There is segfault reported here:<br>
>><br>
>> <a href="http://projects.scipy.org/numpy/ticket/1588" target="_blank">http://projects.scipy.org/numpy/ticket/1588</a><br>
>><br>
>> I've managed to isolate the problem and even provide a simple patch,<br>
>> that fixes it here:<br>
>><br>
>> <a href="https://github.com/numpy/numpy/issues/398" target="_blank">https://github.com/numpy/numpy/issues/398</a><br>
>><br>
>> however the patch simply doesn't decrease the proper reference, so it<br>
>> might leak. I've used<br>
>> bisection (took the whole evening unfortunately...) but the good news<br>
>> is that I've isolated commits<br>
>> that actually broke it. See the github issue #398 for details, diffs etc.<br>
>><br>
>> Unfortunately, it's 12 commits from Mark and the individual commits<br>
>> raise exception on the segfaulting code,<br>
>> so I can't pin point the problem further.<br>
>><br>
>> In general, how can I debug this sort of problem? I tried to use<br>
>> valgrind, with a debugging build of numpy,<br>
>> but it provides tons of false (?) positives: <a href="https://gist.github.com/3549063" target="_blank">https://gist.github.com/3549063</a><br>
>><br>
>> Mark, by looking at the changes that broke it, as well as at my "fix",<br>
>> do you see where the problem could be?<br>
>><br>
>> I suspect it is something with the changes in PyArray_FromAny() or<br>
>> PyArray_FromArray() in ctors.c.<br>
>> But I don't see anything so far that could cause it.<br>
>><br>
>> Thanks for any help. This is one of the issues blocking the 1.7.0 release.<br>
><br>
> IIRC you can recompile Python with some support for detecting memory<br>
> leaks. One of the issues with using Valgrind, after suppressing the<br>
> false positives, is that Python uses its own memory allocator so that<br>
> sits between the bug and what Valgrind detects. So at least recompile<br>
> Python to not do that.<br>
<br>
</div></div>Right. Compiling with "--without-pymalloc" (per README.valgrind as suggested<br>
above by Richard) should improve things a lot. Thanks for the tip.<br>
<div class="im"><br>
><br>
> As for hardening the NumPy source in general, you should at least be<br>
> aware of these two options:<br>
><br>
> 1) David Malcolm (<a href="mailto:dmalcolm@redhat.com">dmalcolm@redhat.com</a>) was writing a static code<br>
> analysis plugin for gcc that would check every routine that the<br>
> reference count semantics was correct. (I don't know how far he's got<br>
> with that.)<br>
><br>
> 2) In Cython we have a "reference count nanny". This requires changes to<br>
> all the code though, so not an option just for finding this bug, just<br>
> thought I'd mention it. In addition to the INCREF/DECREF you need to<br>
> insert new "GIVEREF" and "GOTREF" calls (which are noops in a normal<br>
> compile) to declare where you get and give away a reference. When<br>
> Cython-generated sources are enabled with -DCYTHON_REFNANNY,<br>
> INCREF/DECREF/GIVEREF/GOTREF are tracked within each function and a<br>
> failure is raised if the function violates any contract.<br>
<br>
</div>I see. That's a nice option. For my own code, I never touch the<br>
reference counting<br>
by hand and rather just use Cython.<br>
<br>
<br>
In the meantime, Mark fixed it:<br>
<br>
<a href="https://github.com/numpy/numpy/pull/400" target="_blank">https://github.com/numpy/numpy/pull/400</a><br>
<a href="https://github.com/numpy/numpy/pull/405" target="_blank">https://github.com/numpy/numpy/pull/405</a><br>
<br>
Mark, thanks again for this. That saved me a lot of time.<br></blockquote><div><br></div><div>No problem. The way I prefer to deal with this kind of error is use C++ smart pointers. C++11's unique_ptr and boost's intrusive_ptr are both useful for painlessly managing this kind of reference counting headache.</div>
<div><br></div><div>-Mark </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ondrej<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br>