On Thu, 4 Aug 2005, Leopold Toetsch wrote:
Michal Wallace wrote:
And wouldn't you know it... A bug on the parrot
side cropped up out of nowhere to break them!
==17366== valgrind's libpthread.so: IGNORED call to: pthread_attr_destroy
==17366== Invalid read of size 4
==17366== at 0x43D5123E: Parrot_PyTuple_get_iter (in
/home/lt/svn/parrot/leo/runtime/parrot/dynext/python_group.so)
==17366== by 0x8115576: Parrot_iter_p_p (ops/experimental.ops:231)
Unfortunately valgrind doesn't show line numbers from the shared lib, but
PyTuple.get_iter() is short enough so that you should be able to track down
the problem.
Thanks, Leo!!
I'm afraid this is gibberish to me, but I gave it a shot.
I compared the code for pytuple to pylist and pystring
and noticed they use the python iterator instead of the
enum_class one. Also, pylist references in there several
times but it only appears once for pytuple, which can't
change its length. It looks like the other length tests
for pytuple use PMC_int_val instead so I changed that.
Anyway, I have no idea what I'm doing here but it seems
to have fixed the tests. I don't have commit access.
Assuming you don't see anything horribly wrong here,
would you mind applying this patch?
BTW, the problem is on red hat enterprise linux 3.0 with
a fresh build from subversion)
- Michal
http://withoutane.com/
Index: pytuple.pmc
===================================================================
--- pytuple.pmc (revision 8800)
+++ pytuple.pmc (working copy)
@@ -155,12 +155,12 @@
*/
PMC* get_iter () {
- PMC *iter = pmc_new_init(INTERP, enum_class_Iterator, SELF);
+ PMC *iter = pmc_new_init(INTERP, PyBuiltin_PyIter, SELF);
PMC *key = pmc_new(INTERP, enum_class_Key);
PMC_struct_val(iter) = key;
PObj_get_FLAGS(key) |= KEY_integer_FLAG;
PMC_int_val(key) = 0;
- if (!((List *) PMC_data(SELF))->length)
+ if (!((List *) PMC_int_val(SELF)))
PMC_int_val(key) = -1;
return iter;
}
