[info-performer] Strange problem when using pfMalloc'd memory

New Message Reply Date view Thread view Subject view Author view

From: John Harrison (john++at++immersence.com)
Date: 11/01/2002 10:13:42


Hi everyone,

I'm using Performer 2.4.2 on a Linux system, running Red Hat Linux 7.1
(SMP), and I have been having problems when setting pfMalloc'd memory to
certain very specific values.

As I understand it, when you use pfMalloc() to allocate memory, an extra
4-word header is allocated before the returned data pointer. Using
pfGetMemory() should give the address of this header and pfGetData() should
give the address of the data.

However, I find if I set the data to certain values, suddenly pfGetMemory()
will return the address of the DATA, and pfGetData() may crash! Also, the
sizes, access counts, and everything else will be completely messed up.

So my question is: does Performer use some sort of tag to indicate that an
arbitrary memory pointer is a pointer to the header? If this is true, I may
be inadvertently setting this tag, and it would explain the symptoms I'm
seeing.

I'd appreciate any insights anyone may have on this.

Thanks,

-John Harrison

P.S. Here's a program fragment which consistently exhibits this problem on
my system (though the specific values to cause this problem may be different
on your system). For me, this only happens for the float 7.300453 with the
program below; other float values don't crash (even 7.300452 will not
crash!).

----------

    float *ptr;

    ptr = (float *)pfMalloc(sizeof(float),pfGetSharedArena());

    *ptr = 42.0;
    // At this point, everything is fine - pfGetSize(ptr) returns 4, and
pfGetMemory(ptr) returns an address 16 bytes before the pointer

    *ptr = 7.300453;
    // Now, everything will be messed up - pfGetSize(ptr) will return a 0,
and pfGetMemory(ptr) returns the same address as the pointer

    pfDelete(ptr); // This will crash (segmentation fault).

----------


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Fri Nov 01 2002 - 10:14:57 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.