Detecting malloc'd mem

[lemons]

Hi guys,

I was wondering if there is a way to work out if an address is malloc'd and/or how big or what range the memory 'section' is.

Like, say, I malloc 8 bytes at 0xC010 and later on I want to try and access it. Taking a gamble, and trying to access this if it is not malloc'd will of course cause a segfault.

I guess handling the signal is one crude way round this, but is there some method that i can use like (imaginatively named) is_alloc(void*) and it will safely tell me if a byte is allocated? Also, maybe it could tell me the start and end of the allocated 'block'? (I don't know what the term is for a single malloc'd region of memory.)

Thanks!

Adam

[JohnGraham]

Taking a gamble, and trying to access this if it is not malloc'd will of course cause a segfault.

It will not necessarily cause a segfault. A segfault is what happens when you try and access memory outside of your address space - however, memory may be inside your address space without having been allocated to you by malloc(), so you can access this unallocated memory without causing a segfault. You're very right to avoid going down that route!

Also, this immediately hits me as a task you shouldn't really need to do. Can I ask why you think you do? You have to remember, just because a block of memory has been allocated doesn't mean it's been allocated to you as the application programmer - some library may have requested it.

However, one way you can keep track of all your own application-level memory blocks is to simply always call malloc(), free(), calloc() and realloc() through some intermediary functions which keep track of what's been allocated, and you can look this up when you need to.

[lemons]

Thanks for the reply. Yes, I know I shouldn't; it was mainly just out of interest, since it's one of the things I've not heard of before, and could possibly be useful in some as of yet uncertain circumstances!

Do you know of a way?

Cheers

[chaosless]

here's a test program that i've used to check for address ranges - esp on 64bit models.

#include <stdlib.h>
#include <stdio.h>
#include <alloca.h>

extern char etext, edata, end;
/*
extern char __stack;
extern char _ebss;
*/

char global_buffer[128];

int main( int argc, const char *argv[], const char *envp )
{
char stack_buffer[128];
static char static_buffer[128];
char *cp = malloc( 128 );
char *ap = alloca( 128 );
char *xp = "STRING CONSTANT";

printf("argv[0] %p\n",argv[0]);
printf("envp %p\n",envp);
printf("stack %p\n",stack_buffer);
printf("global %p\n",global_buffer);
printf("static %p\n",static_buffer);
printf("malloc %p\n",cp);
printf("alloca %p\n",ap);
printf("const %p\n",xp);
printf("printf %p\n",printf);


printf("First address past:\n");
printf(" program text (etext) %p\n", &etext);
printf(" initialized data (edata) %p\n", &edata);
printf(" uninitialized data (end) %p\n", &end);

/*
printf("_ebss %p\n",&_ebss);
printf("__stack %p\n",&__stack);
*/
}

[lemons]

Thanks chaosless. The first thing I notice is <alloca.h> which says:

/* Allocate a block that will be freed when the calling function exits.  */
extern void *alloca (size_t __size) __THROW;

which I've never come across before. My first thought is this is how C actually allocates memory for static variables, i.e. variables with a lifetime up to the end of the scope of the method (usually) that creates them? Is that correct?

As for most of the other things, I'm not sure what they mean. Could you refine please?

Thanks,

Adam

[jonsg]

I was wondering if there is a way to work out if an address is malloc'd and/or how big or what range the memory 'section' is.

Like, say, I malloc 8 bytes at 0xC010 and later on I want to try and access it. Taking a gamble, and trying to access this if it is not malloc'd will of course cause a segfault.

It seems to me that you're asking the wrong question. If you don't already know if a given pointer address is within an allocated memory extent, why on Earth are you trying to dereference it?

Dereferencing unknown pointers is a guaranteed disaster area. What if the extent has been deallocated, then partially reallocated to a different purpose, and you're about to scribble over someone else's data structure? It gets worse in an MMU-less environment where there's no memory protection - with nothing to prevent you, you can write into system-critical structures. You won't know about it until an inexplicable crash some way down the line, as the effects of the ill-advised write snowball.

If you're trying to determine whether you're leaking memory, there are tools such as valgrind, mtrace and so on that will help diagnose allocation errors and malloc/free imbalances, and I'd recommend you use those.

[chaosless]

the routine just demonstrates the various segments in which various things can exist.

static variables - whether specified inside a function or just within the compile unit - are assigned their space at compile time, unlike malloc() or alloca() addresses that are created dynamically. there is no free() for them of course.

alloca() works like malloc() - but instead extends the stack frame and interposes a cleanup routine so the address is automagically free()d when the routine that called alloca() returns.

argv[], envp, are setup by at image activation

from "man etext" page:
etext - first address past the end of the text segment (the program code).
edata - first address past the end of the initialized data segment.
end - first address past the end of the uninitialized data segment (also known as the BSS segment).

see also "man sbrk"

[lemons]

Thanks jonsg. It is a stupid question, I know; like I said, if, in as of yet uncertain circumstances, I wanted to check if I had malloc'd some memory, why shouldn't I be allowed to perform such a check? Admittedly, there are easy ways of remembering, such as setting free'd pointers to NULL and so on, which I try to do. It is purely my curiosity!

Now that I think about it, I do occasionally experience strange behaviour when declaring a pointer type inside a method, which sometimes causes the elements to be equal to not NULL, and other times NULL. I understand this could be an incredible coincidence, but it does make me think. I find myself having to write a small FOR loop assigning elements of an array to NULL after no errors used to occur, until adding lines of code seemingly unrelated to these declarations.

Luckily, I've learned through university that computers really aren't to be trusted, so naturally I don't expect the expected behaviour.

chaosless: thanks, I'll look over the man pages.

Cheers

[jonsg]

alloca() is something to be treated with great care.

Firstly: the pointer goes out of scope when you return from the function within which you allocated the memory. If you return the alloca()ed pointer from your function, or assign it into a structure that outlives the function, you'll have a fun time discovering the bug.

Secondly, you have to be careful not to overflow the stack. That doesn't usually matter for desktop systems - the OS will quietly add more pages ahead of the stack pointer when it page-faults - but in embedded systems where there can be a strictly limited and fixed stack space allocation for an executable, it can cause disaster. Best used for very small allocations.

Thirdly, It's also worth noting that alloca() isn't a universally supported call. Even within a given platform, it may be available only with some compilers.

Finally, the compiler has to be smart enough to special-case alloca() calls. The classic example is this:

func(alloca(23), alloca(42));

Think carefully about how stack and frame pointer registers are manipulated when compiling this code! If it isn't special-cased correctly, you'll get unexpected and calamitous consequences.

[lemons]

alloca() is something to be treated with great care...

Thanks! I must admit I thought it sounded too good to be true from the method description. I tend to stick to my {m,c}alloc()'s!

So, all aside, it seems that there is no solution to find out if a memory address is malloc'd in the current process' context? It's a shame, because I think that it may have some use in certain situations, possibly involving volatile variables? Again, I'm not clued-up on the knowledge.

Thanks,

Adam