On Sunday 08 July 2007 14:45:53 Bob Rogers wrote:
> From: James E Keenan <[EMAIL PROTECTED]>
> Date: Sun, 08 Jul 2007 15:18:21 -0400
>
> On Debian 4.0 Linux, t/examples/shootout.t is failing even more tests
> than yesterday. See attached.
>
> kid51
>
> I get the same failures on SuSE 9.0 GNU/Linux, Parrot r19701. Here's an
> interesting observation:
>
> [EMAIL PROTECTED]> ./parrot t/examples/shootout_13.pir
> 3141592653 :10
> 5897932384 :20
> 6264338 :27
> [EMAIL PROTECTED]> ./parrot -C t/examples/shootout_13.pir
> Segmentation fault
> [EMAIL PROTECTED]> ./parrot -Cj t/examples/shootout_13.pir
> Segmentation fault
> [EMAIL PROTECTED]> ./parrot -Cg t/examples/shootout_13.pir
> Segmentation fault
> [EMAIL PROTECTED]>
>
> The backtraces all look similar, failing deep in glibc, which puts it
> out of my depth.
Binary search (and about a week's worth of digging on my part) blames r19570.
I think it's this part:
Modified: trunk/include/parrot/pobj.h
==============================================================================
--- trunk/include/parrot/pobj.h (original)
+++ trunk/include/parrot/pobj.h Tue Jul 3 16:28:16 2007
@@ -141,6 +141,7 @@
struct PMC {
pobj_t obj;
VTABLE *vtable;
+ PMC *real_self;
#if ! PMC_DATA_IN_EXT
DPOINTER *data;
#endif /* ! PMC_DATA_IN_EXT */
Something, somewhere, isn't happy about this struct changing size. I didn't
notice anything in *specific* which looked wrong.
I did note that PMC_EXT instances get allocated out of memory pools too, and
within src/gc/smallobject.c's Parrot_add_to_free_list(), the line:
PObj_flags_SETTO((PObj *)object, PObj_on_free_list_FLAG);
... casts them to PObj pointers, which is a problem becase dereferencing that
memory is sort of... ugh:
typedef struct PMC_EXT {
#if PMC_DATA_IN_EXT
DPOINTER *data;
#endif /* PMC_DATA_IN_EXT */
PMC *_metadata; /* properties */
struct _Sync *_synchronize;
PMC *_next_for_GC;
} PMC_EXT;
Note the lack of pobj_t in there. Gonna be hard to deference *that*.
-- c
