0 readanysf~.pd_darwin 0x006a8f48 flext_root_multi::operator new(unsigned long) + 0x14 1 readanysf~.pd_darwin 0x006a8f58 flext_root_multi::operator new(unsigned long) + 0x24 2 readanysf~.pd_darwin 0x006a8f58 flext_root_multi::operator new(unsigned long) + 0x24 3 readanysf~.pd_darwin 0x006a8f58 flext_root_multi::operator new(unsigned long) + 0x24 4 readanysf~.pd_darwin 0x006a8f58 flext_root_multi::operator new(unsigned long) + 0x24
Oh wow, i'll have to have a look.... that seems to be caused by minor changes introduced lately... 0.4.5 could be fine though.
i've experienced problems with the recent flext and readanysf~, too ... not on a mac, but on a linux machine ...
i did a backtrace with ddd and it seems that flext_root_multi::operator new() as it's run by readanysf::__init__() runs itself recursively for (on my setup) 261771 times ...
i don't fully understand your code, but it seems that in line 6 you try to run the same function, again without changing the parameter (bytes) ...
void *flext_root::operator new(size_t bytes) { bytes += sizeof(size_t);
char *blk;
if(bytes >= LARGEALLOC) {
// use C library function for large memory blocks
blk = (char *)::operator new(bytes);
}
else {
//! \todo We need system locking here for secondary threads!
#if FLEXT_SYS == FLEXT_SYS_JMAX blk = (char *)::fts_malloc(bytes); #else blk = (char *)::getbytes(bytes); #endif }
*(size_t *)blk = bytes;
return blk+sizeof(size_t);
}
i might be wrong (i don't understand the meaning of (char *)::, but that would explain the behaviour...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac