memory problems on K580

[Joe Hege]

I've seen questions kinda like this so I hope some of you can help me. I'm trying to allocate (malloc, in C) fairly reasonable amounts of memory (@20-30MB) on a K580 running OS 10.20. I have tested, however, and found that a malloc(_) of any amount of memory >3888bytes fails and the process ends in a core dump. I've checked maxssiz and found it is sufficient for my needs. Why oh why can't I have more RAM?

[A. Clay Stephenson]

Hi Joe:

First, maxssiz has nothing to do with malloc the parameter you need to look at is maxdsiz. In your case, however, I don't think you are hitting that limit either. I assume that you are testing the result from malloc(). It should return a NULL value if memory is not available and set errno to ENOMEM. Make sure that those tests are in place. The most common cause of the failure you describe is that free has been called with a bogus value and thus the heap has become corrupted.

Clay

[Praveen Bezawada]

Hi
You should be looking at maxdsiz or maxdsiz_64 for 64 bit systems.
maxdsiz and maxdsiz_64bit define the maximum size of the static data storage segment of an executing process for 32-bit and 64-bit processors, respectively. This segment contains fixed data storage such as globals, arrays, statics, locals to main(), strings, space allocated using sbrk() and malloc(), and such.

...BPK...

[A. Clay Stephenson]

Hi Again,

You might try installing PHCO_23684 but I'm still betting that you have somehow clobbered your pointer by calling free with a bogus value or freeing the same block more than once.
You might try putting probes in to look at the few few bytes of the block pointed to.

[Joe Hege]

I appreciate your working with me on this. I have checked maxdsiz and it is plenty large enough. I also have been testing my return on malloc(_) and I still find that requests above a certain level result in core dumps, though I am not sure that level is the same as the last time I tested. I'm intrigued by Clay's idea of a corrupt heap from the call, but there are no free(_) calls taking place in the code up to that point, though a number of other mallocs are made. I stepped through the code and found that the total memory before my big malloc is about 1MB. I tried the patch Clay suggests on our development box (the K580), but there has been no improvement. I think it is also important to note that with some minor porting differences the program runs perfectly on my desktop NT box.

[A. Clay Stephenson · Accepted solution]

Just because it works on NT means very little.
The architectures are very different. Next thing to look for is something like this:

char s1[8];
char *p = NULL;
char s2[8];
int i = -2;

p = (char *) malloc((size_t) 32 * 1024 * 1024);
(void) sprintf(s1,"This is too big for s1");
(void) sprintf(s2,"This is too big for s2");

p[i] = 'X';

Any of this stuff could cause problems and especially the p[-2] references since this can clobber critical housekeeping areas of the memory block itself. Later mallocs can then be clobbered.

This may be the time to learn about the symbolic debugger xdb.