Thank you. At least I can exclude another few error sources, now.
Cédric Lucantis wrote:
> I see nothing wrong with your code so I'd say it is somewhere else (did
> you snip any code between the end of the loop and the return?).
No. (Apart from freeing allocated memory.)
> I've never
> seen those 'refcnt' objects but a refcount of 0 sounds like you unrefed
> your objects one extra time by mistake. This would produce a segfault on
> unix, but maybe not on all platforms ?
Well, I am working on Linux. Python 2.5.1, gcc 4.1.3 . And I do not see
segfaults until I start working in Python with the return value of that
function, of course.
> You should check the return value
> of PyList_Append()
It is always 0, regardless of what I do.
> and if it doesn't help trace the content of your list
> after each iteration to see when the bad things happen (you can check the
> reference count of an object with obj->ob_refcnt).
Seems ok. What I did to check this was placing this after building the list:
for (i=0; i < limit; i++) {
dummy = PyList_GetItem(python_return_value, i);
printf("%f\n", PyFloat_AsDouble(dummy));
Py_CLEAR(dummy);
}
Which gives reasonable numbers.
>
> Finally note that in your case it would be much simpler and more efficient
> to use the float constructor directly:
>
> dummy = PyFloat_FromDouble(internal_list([i]))
I tried that (actually PyFloat_FromDouble(internal_list[i]) ): Same thing,
but now more like [<refcnt -1 at 0x94a474c>, <refcnt -1 at 0x94a475c>, etc.
(Note the -1.)
>
> PS: always use Py_CLEAR(dummy) instead of Py_DECREF(dummy); dummy=NULL;
> (though it doesn't really matter in this simple case - see
> http://docs.python.org/api/countingRefs.html)
Good idea! Since I require 2.4 for users anyway, there is no harm in
reducing the code.
Christian
--
http://mail.python.org/mailman/listinfo/python-list
