As my small contribution, attached is a small shell script that, unmodified, finds out how many times certain functions are called in a given sample of files. The default functions are 'malloc', 'realloc', and 'free', and the sample files are all files ending in .c in the current directory. It even prints out the result in a neat manner on ANSI colourized terminals.
The script is very flexible, and easy to modify.
Current version is 256bytes long.
Segin wrote:
As my small contribution, attached is a small shell script that, unmodified, finds out how many times certain functions are called in a given sample of files. The default functions are 'malloc', 'realloc', and 'free', and the sample files are all files ending in .c in the current directory. It even prints out the result in a neat manner on ANSI colourized terminals.
The script is very flexible, and easy to modify.
Current version is 256bytes long.
Hmmm, I'm affraid this isn't telling much, consider:
int main() { int i; char *ptr; for (i = 0; i < 10; i++) ptr = malloc(20); free(ptr); return 0; }
you're script will report one 'malloc' and one 'free', but ten times a 'malloc' is executed and only one 'free' ... :-/
It's not a C interpeter, it's literally a frint end of sorts to grep. There's only one textual occurence of malloc() in the code, so it only returns one.
Think before you speak.
P.S. I'll add a C interpeter when there becomes a need for one.
Joris Huizer wrote:
Segin wrote:
As my small contribution, attached is a small shell script that, unmodified, finds out how many times certain functions are called in a given sample of files. The default functions are 'malloc', 'realloc', and 'free', and the sample files are all files ending in .c in the current directory. It even prints out the result in a neat manner on ANSI colourized terminals.
The script is very flexible, and easy to modify.
Current version is 256bytes long.
Hmmm, I'm affraid this isn't telling much, consider:
int main() { int i; char *ptr; for (i = 0; i < 10; i++) ptr = malloc(20); free(ptr); return 0; }
you're script will report one 'malloc' and one 'free', but ten times a 'malloc' is executed and only one 'free' ... :-/
Segin wrote:
It's not a C interpeter, it's literally a frint end of sorts to grep. There's only one textual occurence of malloc() in the code, so it only returns one.
Think before you speak.
P.S. I'll add a C interpeter when there becomes a need for one.
It was my impression that the goal was to find leaks by counting allocating and freeing of memory; My example was about that: the counts do not have to indicate correct usage of malloc()/free() Sorry if this was an incorrect assumption
regards,
Joris
Joris Huizer wrote:
Segin wrote:
It's not a C interpeter, it's literally a frint end of sorts to grep. There's only one textual occurence of malloc() in the code, so it only returns one.
Think before you speak.
P.S. I'll add a C interpeter when there becomes a need for one.
It was my impression that the goal was to find leaks by counting allocating and freeing of memory; My example was about that: the counts do not have to indicate correct usage of malloc()/free() Sorry if this was an incorrect assumption
Right. And by reading the code that is doing alloc/free you can determine if they are balanaced. But first you have to *find* where those calls are made.
Jim
Jim White wrote:
Joris Huizer wrote:
Segin wrote:
It's not a C interpeter, it's literally a frint end of sorts to grep. There's only one textual occurence of malloc() in the code, so it only returns one.
Think before you speak.
P.S. I'll add a C interpeter when there becomes a need for one.
It was my impression that the goal was to find leaks by counting allocating and freeing of memory; My example was about that: the counts do not have to indicate correct usage of malloc()/free() Sorry if this was an incorrect assumption
Right. And by reading the code that is doing alloc/free you can determine if they are balanaced. But first you have to *find* where those calls are made.
Jim
This gives me an idea: I can add a command line flag to determine how to invoke grep (e.g. just a count, or a count plus occurences by line)
That's ok, I failed to document that myself. In truth, it would truthfully be inpossible to find run-time memory leaks like that using a script because of a potential unknown variable in a for loop which is derived from an argument or return from another function.
I will try to add code for detecting contant for loops at one point.
Also, the script is designed to be edited and whatever function you want to look for inserted into the code.
Joris Huizer wrote:
Segin wrote:
It's not a C interpeter, it's literally a frint end of sorts to grep. There's only one textual occurence of malloc() in the code, so it only returns one.
Think before you speak.
P.S. I'll add a C interpeter when there becomes a need for one.
It was my impression that the goal was to find leaks by counting allocating and freeing of memory; My example was about that: the counts do not have to indicate correct usage of malloc()/free() Sorry if this was an incorrect assumption
regards,
Joris
-
Jim White -
Joris Huizer -
Segin