GCC (g++) Memory allocation issues

Ok this is really starting to annoy me now :(

I'm trying to port this project to 68k (020) using gcc V2.9.5.3 (CubicIDE) and I'm having memory issues. The code is a large C++ project with a mixture of new(), malloc() and calloc().

There seems to be some kind of arbitrary limit of memory that causes the program to crash. The only way I've managed to get it run is to convert all of the calls from malloc()/calloc() to the AllocMem() which I obviously shouldn't have to do.

Currently I've got the compiler setup to store the data as 'FAR', does it need to be set to 'EXTRA FAR' or something silly like that?

Help!

You dont have to convert malloc() to AllocMem(). Just write your own malloc()/free() functions using AllocMem() and track allocations.

But I dont think problem is in malloc() or in new operator. Most likely your project has buffer overflow somewhere. I recommend using Wipeout tool from Aminet to find out.

AFAIK the FAR operator only affects pointers like those stored in the global data segment and not how to what extent or how far across memory can be in relation to any size limit. But I did some research and found there is a farmalloc() function. You don't need a whole farm to store your memory, no? Hehe. ;-)

So there is small model and large model (far). Small can use a register to store the global base location and reference data as an offset, usually 16-bit, and with fast access. Large would just use 32-bit pointers direct in memory and was usually slower. With 32-bit code (020+) generated 32-bit offsets can be referenced off a base register so large model could be used without a speed loss.

If the memory alloc routines are crashing they'd be badly written as they should return NULL! It's possible they are taking memory of a local heap for short allocations. What I wonder is the stack? How large is your stack? :-)

Ok I think I've found the problem at last.

In parts of the code it calls calloc() but passes in zero for the number variable (the first parameter). In other implementations this would just result in no memory being allocated and calloc() would simply return NULL but in gcc 68k it blows up!

Oh well, glad I've finally figured this one out after all this time.

Yeah, asking a routine to allocate nothing would confuse it somewhat. ;-)

Now, why is it trying to allocate nothing?

And, with AllocMem() not crashing, were you able to track where it failed?

Hiya,

Yep AllocMem() is obviously a little more 'system friendly' than the 68k gcc implementation.

I can't really change their source code so I'll just set up a define and route it through my own function (ie check for zero allocation and return NULL if detected).

this is funny.

So to fix this issue I created a define, like this:

#define calloc(num, size) callocEx(num, size)

With the idea being that I could redirect all of the original code to my new 'gcc friendly' versions which I want to INLINE in a header file like this:

inline void* callocEX(size_t num, size_t size) {
if(num >0) {
return calloc(num, size);
} else {
return NULL;
}
}

But I don't want the #define to remap the nested calloc call as I'd get a circular reference :)

So what's the best way around this? Wrap the method in a #undef and then redefine it again?

Something like this won't work?...

#define malloc(size) AllocVec(size,MEMF_ANY)
#define calloc(num,size) AllocVec(num*size,MEMF_CLEAR)
#define free(ptr) FreeVec(ptr)

I believe AllocVec() will handle the NULLs. If you think the multiplication is slower, I bet that's what calloc() does anyway. Multiplication isn't that slow on newer processors anyway. The way I suggest should be faster if it works. You would have to include the appropriate AmigaOS includes of course.

Blows up how? Are you sure it's just calloc()? It could be that at some points malloc() is called with a zero length parameter, too.

If the code came from a Unix system, it's possible that it expects calloc() to return a non-NULL result if the first parameter is zero. This is actually permitted by the ISO 'C' language standard and its counterpart POSIX because some systems will return a non-NULL result if malloc(), which calloc() is built upon, receives a zero length parameter.

Optimistically called "implementation defined behaviour", you are in for a surprise if the system you deploy your code on is not sharing the relevant implementation details with the one it was developed for.

Here's one way to try this. Add you own calloc() function which works something like this:

void * calloc(size_t count,size_t size)
{
size_t total_size;
void * result;

total_size = count * size;
if(total_size == 0)
total_size = sizeof(void *); /* Or any size you prefer */

result = malloc(total_size);
if(result != NULL)
memset(result,0,total_size);

return(result);
}

This function returns a non-NULL result unless it runs out of memory. It will always allocate at least as much memory as is required to store a single pointer, which may or may not be enough.

Writing a malloc() replacement that returns a non-NULL result for a zero length parameter is tricker, though...

You could also make up your own functions and put an assert in so you know where in the code zero is being passed.