This is what I came up with:
https://gist.github.com/1496028
We'll see if it helps, tomorrow.
On Sunday, December 18, 2011 6:01:50 PM UTC-8, buck wrote:
> Thanks Jack. I think printf is what it will come down to. I plan to put a
> little code into PyDict_New to print the id and the line at whic
Thanks Jack. I think printf is what it will come down to. I plan to put a
little code into PyDict_New to print the id and the line at which it was
allocated. Hopefully this will show me all the possible suspects and I can
figure it out from there.
I hope figuring out the file and line-number fr
I don't have any great advice, that kind of issue is hard to pin down.
That said, do try using a python compile with --with-debug enabled,
with that you can turn your unit tests on and off to pinpoint where
the refcounts are getting messed up. It also causes python to use
plain malloc()s so valgr
On Saturday, December 17, 2011 11:55:13 PM UTC-8, Paul Rubin wrote:
> buck writes:
> > I tried to pinpoint this intermediate allocation with a similar
> > PyDict_New/LD_PRELOAD interposer, but that isn't working for me[2].
>
> Did you try a gdb watchpoint?
I didn't try that, since that piece of
buck writes:
> I tried to pinpoint this intermediate allocation with a similar
> PyDict_New/LD_PRELOAD interposer, but that isn't working for me[2].
Did you try a gdb watchpoint?
--
http://mail.python.org/mailman/listinfo/python-list
I'm getting a fatal python error "Fatal Python error: GC object already
tracked"[1].
Using gdb, I've pinpointed the place where the error is detected. It is an
empty dictionary which is marked as in-use. This is somewhat helpful since I
can reliably find the memory address of the dict, but it d
