what helpful
> > > since I can reliably find the memory address of the dict, but it does not
> > > help me pinpoint the issue. I was able to find the piece of code that
> > > allocates the problematic dict via a malloc/LD_PRELOAD interposer, but
> > > that co
> > python. I don't think it was the cause.
> >
> > I believe that the dict was deallocated, cached, and re-allocated via
> > PyDict_New to a C routine with bad refcount logic, then the above error
> > manifests when the dict is again deallocated, cached, and re-alloc
allocates the
> problematic dict via a malloc/LD_PRELOAD interposer, but that code was pure
> python. I don't think it was the cause.
>
> I believe that the dict was deallocated, cached, and re-allocated via
> PyDict_New to a C routine with bad refcount logic, then the above err
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
ated via
PyDict_New to a C routine with bad refcount logic, then the above error
manifests when the dict is again deallocated, cached, and re-allocated.
I tried to pinpoint this intermediate allocation with a similar
PyDict_New/LD_PRELOAD interposer, but that isn't working for me[2].
How sh
Christian Heimes <[EMAIL PROTECTED]> writes:
> Berthold Höllmann wrote:
>> Is there any "common" reason to for such a strange object on the command
>> stack, or is it more likely that any of my extension modules is causing
>> havoc?
>
> It's very likely that your extension has a reference counting
Berthold Höllmann wrote:
Is there any "common" reason to for such a strange object on the command
stack, or is it more likely that any of my extension modules is causing
havoc?
It's very likely that your extension has a reference counting bug. It
looks like you are either missing a Py_INCREF o
I have a problem with my debug Python 2.5.2 executable with Py_REF_DEBUG
and Py_TRACE_REFS set. With one of my scripts I get:
...
Fatal Python error: Python/ceval.c:947 object at 0x2aa3f4d840 has negative ref
count -2604246222170760230
Program received signal SIGABRT, Aborted.
[Switching to Thre
Benjamin <[EMAIL PROTECTED]> wrote:
>> [ help(sys.getrefcount) says: ]
>> [ ... ] The count returned is generally
>> one higher than you might expect, because it includes the (temporary)
>> reference as an argument to getrefcount().
>Are there any cases when it wouldn't?
When the temporary refer
Benjamin wrote:
> On Jan 29, 5:46 am, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> Simon Pickles wrote:
>>> Hi,
>>> Is is possible to access the refcount for an object?
>>> Ideally, I am looking to see if I have a refcount of 1 before calling del
&
On Jan 29, 5:46 am, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Simon Pickles wrote:
> > Hi,
>
> > Is is possible to access the refcount for an object?
>
> > Ideally, I am looking to see if I have a refcount of 1 before calling del
>
> Help on buil
Simon Pickles wrote:
> Hi,
>
> Is is possible to access the refcount for an object?
>
> Ideally, I am looking to see if I have a refcount of 1 before calling del
Help on built-in function getrefcount in module sys:
getrefcount(...)
getrefcount(object) -> integer
Return t
Simon Pickles <[EMAIL PROTECTED]> wrote:
> Is is possible to access the refcount for an object?
>>> import sys
>>> sys.getrefcount(42)
6
> Ideally, I am looking to see if I have a refcount of 1 before calling del
That's a pointless exercise: you probably d
Hi,
Is is possible to access the refcount for an object?
Ideally, I am looking to see if I have a refcount of 1 before calling del
Thanks
Simon
--
Linux Counter: User# 424693
--
http://mail.python.org/mailman/listinfo/python-list
En Wed, 31 Oct 2007 22:01:53 -0300, <[EMAIL PROTECTED]> escribió:
> i checked this:
> http://svn.python.org/projects/python/trunk/Doc/data/refcounts.dat
> and it seems that
> PyDict_SetItem incref the value being added and the key
> and PyDict_DelItem does not decrement any refcounts
> so i have
i checked this:
http://svn.python.org/projects/python/trunk/Doc/data/refcounts.dat
and it seems that
PyDict_SetItem incref the value being added and the key
and PyDict_DelItem does not decrement any refcounts
so i have to do so manually for the key and for the data( by calling
PyDict_GetItem first
Hi
With Python 2.5, there is a change on the reference count of objects
compared with previous versions (as reported by sys.getrefcount).
All Python versions from 2.1 thru 2.4 gave these same results:
Python 2.1.3 (#35, Apr 8 2002, 17:47:50) [MSC 32 bit (Intel)] on win32
Type "copyright", "cr
Jens Theisen wrote:
> python uses gc only where refcounts alone haven't yet done the
> job. Thus, the following code
> class Foo:
> def __del__(self):
>print "deled!"
... In c++, this is a central technique used for all sorts of tasks,
whereas in garbage collected languages
Jens Theisen wrote:
> Thus, the following code
>
> class Foo:
> def __del__(self):
> print "deled!"
>
> def foo():
> f = Foo()
>
> foo()
> print "done!"
>
> prints
>
> deled!
> done!
>
> and not the other way round.
the behaviour you see in this simple program is not guarant
"Jens Theisen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> python uses gc only where refcounts alone haven't yet done the
> job.
/python/The CPython implementation/
> And some other minor question: Is there a way to query the use count
> of an object? This would be useful for
On 30 Oct 2006 00:30:53 +, Jens Theisen <[EMAIL PROTECTED]> wrote:
>Hello,
>
>python uses gc only where refcounts alone haven't yet done the
>job. Thus, the following code
>
>class Foo:
>def __del__(self):
>print "deled!"
>
>def foo():
>f = Foo()
>
>foo()
>print "done!"
>
>print
Hello,
python uses gc only where refcounts alone haven't yet done the
job. Thus, the following code
class Foo:
def __del__(self):
print "deled!"
def foo():
f = Foo()
foo()
print "done!"
prints
deled!
done!
and not the other way round.
In c++, this is a central technique used
23 matches
Mail list logo
