swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Swarm-Support] xcalloc question


From: David Camacho Trujillo
Subject: [Swarm-Support] xcalloc question
Date: Fri, 16 Jun 2006 19:05:23 +0200 (CEST)
User-agent: IMP/PHP IMAP webmail program 2.2.8

Hi dear Swarmers,

I have developed a model based on some “old” code for Neural Networks and
Genetic Algorithms, I have actualize them to work similar as the examples in the
tutorial. 
But seems like the code is somehow unstable, from time to time I am experiencing
some problems related to memory allocation like:
“Program received signal SIGSEGV, Segmentation fault.
0x4073fa0e in malloc_consolidate () from /lib/tls/libc.so.6”
or
“Program received signal SIGSEGV, Segmentation fault.
-[ListIndex(linked) _next] (self=0x8239498, _cmd=0x40218600) at List_GEN.m:369”
or 
 *** glibc detected *** free(): invalid pointer: 0x0823a990 ***

I know they are different problems and I have to try every of them separately,
but they are recurrent...(of course I could not really solve them) but somehow
now I believe they could be related to the fact that this “old” code dynamically
allocates memory for  arrays using “xcalloc”, which seems to me extrange. (why
not calloc or malloc?)  Here is one example it used in this code:
weights = (float*)xcalloc (_n*_n, sizeof (float));

However tt is difficult to find information about “xcalloc” under Objective-c
and Swarm, is it deprecated?
 Which is the best way work with variable size arrays under Swarm? 
Searching on the archives I found this:

// 1. determine size of data area needed:
arrSize = #items*sizeof(item); // e.g. 3000*sizeof(double)
// 2. allocate the data from some zone:
myArr = [[self getZone] alloc: arrSize]; // or some other named zone
if (myArr == 0) { }; // error during allocation!
// 3. then if need be, zero the data:
memset(myArr, 0, arrSize);
// NOTE: if arrSize > LONG_MAX, you dump core here. 
// On Intel at least, LONG_MAX = 2^31 = 2Gb
// 4. Finally, to deallocate the memory:
[[self getZone] free: myArr];
// Don't forget to free dynamic arrays before killing the objects 
// that own them ...
It is an old post, but maybe still the best way?
Should I have to change to this?

Ah, I am working with Suse 9.2


Thanks in advance,
David





reply via email to

[Prev in Thread] Current Thread [Next in Thread]