I want to mock functions of the c lib such as malloc without altering too much the original source file (the one that uses malloc).
I tried including a header file "mock.h" like
#ifndef MOCK_H_
# define MOCK_H_
# ifdef MOCK_MODE
# include <sys/types.h>
extern void *my_mock_malloc(size_t n);
void *malloc(size_t n) __attribute__((weak, alias ("my_mock_malloc")));
# endif /* MOCK_MODE */
#endif /* !MOCK_H_ */
but it gives me an error
in file included from ...:
/usr/include/stdlib.h:466:14: error: ‘malloc’ aliased to undefined symbol ‘my_mock_malloc’
extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
GCC alias to function outside of translation unit -AKA- is this even the right tool for the job? gives a partial solution: using the linker I create an alias on a symbol. I can now compile with -Xlinker --defsym "malloc"="my_mock_malloc". The problem is that all my .o files are linked using this option and thus the unit testing framework I use (check) is affected by the mocking (and thus it receives is SIGSEGV when I make my mock function return NULL).
Is there a way to perform such symbol aliasing locally, so I can make my tesing framework use the real malloc? Os is there a better solution than this one?
Most implementations of the C language specify all symbols of the libc as weak, that is, you can override them as needed. Try it out! You can write your own function named malloc and it automatically replaces the library supplied malloc. Have a look at your platforms documentation as there are a couple more functions (like free, realloc, calloc, etc) that you need to implement for a malloc replacement to be complete.
I found a solution which is to include a header file mock.h like
#ifndef MOCK_H_
# define MOCK_H_
# ifdef MOCK_MODE
# include <sys/types.h>
extern void *my_mock_malloc(size_t n);
# define malloc(x) (my_mock_malloc(x))
# endif /* MOCK_MODE */
#endif /* !MOCK_H_ */
but I am still curious about another solution.
You could do it like this:
#include <stdio.h>
#include <stdlib.h>
#define malloc my_malloc
void *my_malloc(size_t size) {
printf ("Called my_malloc\n");
return NULL;
}
int main(void) {
char * array = malloc(100);
return 0;
}
Program output:
Called my_malloc
Although not a full answer to your question, you will find that CppUTest is very useful for testing C code as well, and includes most of the malloc/free library in its mock capabilities, allowing you to control malloc failure and so on. It's also very good for debugging memory allocation issues since it uses a debug allocator.
I found that the framework documentation was however a little lacking in detail and examples.
When I used that framework "in anger" a couple of years ago, I found it necessary to implement my own mocked strdup() function, which I did within the CppUTest source.
https://cpputest.github.io/mocking_manual.html
I added the DeathHandler facility as well, to help capture and diagnose segfaults during test.
Related
I'm developing some modules for an automation system written in C and I need to perform lots of work with hardware. And I see no simple way (like traditional) to debugging things instead of trace logs. So I'm looking for a good practice to log function calls. At least the sequence of calls and return values.
The way it is performed in application is quite straightforward and actually pollutes the code with irrelevant constructions like
int function (int param){
if(trace_level & LOG_FCALLS){
writelog("Entering function()");
}
/* something useful */
if(trace_level & LOG_FCALLS){
writelog("Exit from function()=%d", ret);
}
}
I decided to use a macro that will do all the dirty work. Now it looks like this
#define LOG_E(fn) const char *__fname=fn; printf("LOG: Entry to %s\n",__fname)
#define return(ret) printf("LOG: Exit from %s()=%d\n",__fname,ret)
int testFunc(){
LOG_E("testFunc");
/*do useful things */
return(ret);
}
I see the problems with this code
I'm overriding return statement, and it is requires to write return(ret) all the time instead of return ret. It is easy to forget this issue.
I'm defining string variable within my macro. I'm aware that __func__ macro exists in C99, but my compiler, unfortunately, doesn't support this macro or any other relevant macros.
How to log the values of function arguments?
I'm pretty sure that it is not a new problem and I'm not the first one who faced with it. I'm also aware about AOP thing, but the code instrumentation is not acceptable solution for my system and I haven't found any possibility to do it with my compiler.
So I'm looking for a good ideas how to implement tracing in the most elegant way.
My environment:
Legacy code, C, Watcom 10.x, real-time OS
The super-serious, professional way to do this is to make a separate debug/test project, which is separate from the production code entirely. It goes like this:
Make sure to have a backup/commit on the production code.
Make a hard-copy of the production code on the hard drive. This will become your test project.
Create a .txt log file where you write the full signature of each function you want to log, for example:
int function (int param)
float function2 (void)
...
Create a little PC program/script that takes the above .txt file as input, then searches through the source code for matching lines of function definitions. The PC program will then generate a new .c file based on the original code, where it inserts the debug logging code inside the desired functions, after { and before }. It will take a few hours of your time to make such a program.
Link your test project by using the modified source code created by your script.
The above method is how I do it myself on mission-critical software, where you have requirements from safety standards (MISRA, code coverage etc) saying that no code which is not executed in the final product is allowed.
This method ensures the integrity of the production code and guarantees that no accidental bugs are added to the program by the test/debug code. It also leaves the clutter of compile switches etc out of the production code. And you won't have any old debug code remains in your project that you forgot to delete (otherwise I always forget some snippet of debug code somewhere in my programs).
#if defined(DEBUG_BUILD)
# define START_FUNCTION if(trace_level & LOG_FCALLS){writelog("+++ %s()", __func__)
}
# define END_FUNCTION if(trace_level & LOG_FCALLS){writelog("--- %s()", __func__)
#elif defined (TIMING_BUILD)
# define START_FUNCTION WRITE_TIMED_LOG("+++")
# define END_FUNCTION WRITE_TIMED_LOG("---")
#else
# define START_FUNCTION
# define END_FUNCTION
#endif
int function (int param){
START_FUNCTION;
...
if(error_occurred) {
END_FUNCTION;
return errror_code;
}
...
END_FUNCTION;
return 42;
}
You might customize your compiler to handle that. You could use MELT (to customize your gcc compiler) if you are compiling with GCC.
Maybe you might customize openwatcom (or pay some OpenWatcom expert to do that)...
This works in MS Visual C. You will need different versions of the return macro for different data types (or none).
#include <stdio.h>
#define TRACING
#ifdef TRACING
#define LOG_E printf("Func: %s\n", __FUNCTION__);
#define LOG_R printf("Exit: %s\n", __FUNCTION__);
#define LOG_I(ival) printf("Exit: %s %d\n", __FUNCTION__, ival);
#else
#define LOG_E
#define LOG_R
#define LOG_I(ival)
#endif
int main(void){
int retval = 0;
LOG_E
printf("Hello world!\n");
LOG_I(retval)
return retval;
}
Output:
Func: main
Hello world!
Exit: main 0
I have some C code that I want to do some tests on. It uses malloc, calloc, and free through out the code. I want to change those functions to a custom function that internally calls the original function. For example:
emxArray->size = (int *)malloc((unsigned int)(sizeof(int) * numDimensions));
would become:
emxArray->size = (int *)myMalloc((unsigned int)(sizeof(int) * numDimensions));
where myMalloc is:
void* myMalloc(unsigned size)
{
if (size < 8)
{
//printf("*** Bumped from %d....\n", size);
size = 8;
}
allocated += size;
return malloc(size);
}
As you can see, myMalloc internally calls malloc. It just does some extra stuff. I wanted to replace the usage of malloc through out the code with myMalloc. I have done this successfully by going through all the code and replacing malloc with myMalloc manually, but this is far from ideal. I will be replacing this code on a test only basis, thus the production code should contain only malloc calls. I realize I could also do this with a script, but wanted to just use a define statement in the Makefile:
-Dmalloc=myMalloc
But that also replaces malloc in the myMalloc function, which causes an infinite recursive situation. I tried changing the malloc call in the myMalloc function to malloc_d, and added a second define to the Makefile.
-Dmalloc=myMalloc -Dmalloc_d=malloc
I was thinking that the first define would not replace the malloc_d (which it didn't) and that the second define would only change the malloc_d (which it didn't). I got the same recursive situation. Is there anyway to do this with Makefile defines? Or are multipass pre-compile situations going to always mess this up?
UPDATE:
Ok, so I have started looking at the LD_PRELOAD option that has been pointed out. I thought I had a workable solution, however, I am still having trouble! Here is what I did...
I moved myMalloc() and myFree() out of the main file and into its own file. I then compiled it into a shared library using:
gcc -shared -o libMyMalloc.so -fPIC myMalloc.c
I then added the following 'dummy functions' to the main file:
void* myMalloc(unsigned size)
{
void* ptr;
return ptr;
}
void myFree(void* ptr)
{
}
As you can see, they do nothing.
I added the following defines to the make file:
-Dmalloc=myMalloc \
-Dfree=myFree
I compiled the code and ran it against the libMyMalloc.so library I created:
LD_PRELOAD=/home/rad/Desktop/myMalloc/libMyMalloc.so ./testRegress
However, I am still not getting it to run with the myMalloc functions that are defined in the libMyMalloc.so file.
The simplest solution is to not call malloc directly in your code: If you choose a different name (say MALLOC), it's trivial to switch to a custom allocator.
Example code:
#ifndef MALLOC
#define MALLOC malloc
#endif
For test builds, you'd do -DMALLOC=myMalloc.
It gets more complicated if for some reason you want keep the calls to malloc. Then you'd have to add something like the following after all standard library headers have been included:
#ifdef USE_MY_MALLOC
#undef malloc
#define malloc(SIZE) myMalloc(SIZE)
#endif
You can call the standard library function by using parens, ie
void* myMalloc(unsigned size)
{
...
return (malloc)(size);
}
and enable it via -DUSE_MY_MALLOC.
Considering the additional requirements given in the comments, two approaches come to mind:
pre-process the generated source, textually replacing calls to malloc
intercept inclusion of stdlib.h (assuming that's where MATLAB gets its malloc declaration from)
Your own version of stdlib.h would look something like this:
#ifndef MY_STDLIB_H_
#define MY_STDLIB_H_
#include "/usr/include/stdlib.h"
#undef malloc
#define malloc(SIZE) myMalloc(SIZE)
#endif
Then, you can conditionally add the directory where you've placed that file to the include path. Also note that this is not a particularly robust solution, but it might work for you anyway.
You can use a pointer to a function. In the normal case, make it point to malloc. In debugging mode, let it point to you function.
In some h file:
extern void *(*myMalloc)(size_t size);
In one of you c files:
#ifdef DEBUG
void *(*myMalloc)(size_t size) = dMalloc;
#else
void *(*myMalloc)(size_t size) = malloc; // derived from libc
#endif
I found my solution and wanted to share. Thank you to everyone that contributed and pointed me in the right direction.
I ended up creating my custom library code and compiling it into a shared library:
gcc -shared -o libtmalloc.so -fPIC tmalloc.c
I then modified the makefile to use the shared library and globally define 'malloc' to my custom function name (which internally calls malloc()) to malloc_t, as well as calloc() and free():
gcc -L/home/path/to/mallocTrace -Wall -o test test.c lib/coder/*.c -lm -ltmalloc \
-Dmalloc=malloc_t \
-Dcalloc=calloc_t \
-Dfree=free_t
The defines changed all the function calls for me which were linked to the implementation in the shared library. Because I am using a shared library (which is already compiled), I didn't have to worry about my makefile defines causing a recursive call situation in my custom functions. With this usage, I can take any pre-generated C code from my other tools and observe the memory usage with these simple makefile changes and using my custom malloc trace library.
First of all, I've been searching for an answer here and I haven't been able to find one. If this question is really replicated please redirect me to the right answer and I'll delete it right away. My problem is that I'm making a C library that has a few unimplemented functions in the .h file, that will need to be implemented in the main.c that calls this library. However, there is an implemented function in the library that calls them. I have a makefile for this library that gives me "undefined reference to" every function that's not implemented, so the when I try to link the .o s in the main.c file that does have those implementations I can't, because the original library wasn't able to compile because of these errors.
My question is, are there any flags that I could put in the makefile so that it will ignore the unimplemented headers or look for them once the library is linked?
This is a very old-fashioned way of writing a library (but I've worked on code written like that). It does not work well with shared libraries, as you are now discovering.
If you can change the library design
Your best bet is to rearrange the code so that the 'missing functions' are specified as callbacks in some initialization function. For example, you might currently have a header a bit like:
#ifndef HEADER_H_INCLUDED
#define HEADER_H_INCLUDED
extern int implemented_function(int);
extern int missing_function(int);
#endif
I'm assuming that your library contains implemented_function() but one of the functions in the library makes a call to missing_function(), which the user's application should provide.
You should consider restructuring your library along the lines of:
#ifndef HEADER_H_INCLUDED
#define HEADER_H_INCLUDED
typedef int (*IntegerFunction)(int);
extern int implemented_function(int);
extern IntegerFunction set_callback(IntegerFunction);
#endif
Your library code would have:
#include "header.h"
static IntegerFunction callback = 0;
IntegerFunction set_callback(IntegerFunction new_callback)
{
IntegerFunction old_callback = callback;
callback = new_callback;
return old_callback;
}
static int internal_function(int x)
{
if (callback == 0)
...major error...callback not set yet...
return (*callback)(x);
}
(or you can use return callback(x); instead; I use the old school notation for clarity.) Your application would then contain:
#include "header.h"
static int missing_function(int x);
int some_function(int y)
{
set_callback(missing_function);
return implemented_function(y);
}
An alternative to using a function like set_callback() is to pass the missing_function as a pointer to any function that ends up calling it. Whether that's reasonable depends on how widely used the missing function is.
If you can't change the library design
If that is simply not feasible, then you are going to have to find the platform-specific options to the code that builds shared libraries so that the missing references do not cause build errors. The details vary widely between platforms; what works on Linux won't work on AIX and vice versa. So you will need to clarify your question to specify where you need the solution to work.
I have a static C library that I can build with different compile time options (e.g. _BUILD_SMALL, _BUILD_FAST). It has a function
void Foo(void);
I would like to use a single instance of a benchmarking tool to benchmark the "small" and the "fast" versions of the library. I don't want to use .dlls.
How can I link to the "small" and the "fast" libraries and alias the function names so I can call the small version and the fast version. Ideally it would look something like:
void benchmark(void)
{
FAST_Foo();
SMALL_Foo();
}
More information:
The library can be built with different optimizations options -Os versus -O3. Also, the algorithms vary slightly (i.e. cached values vs looking up values always). I want to compare the size vs speed tradeoffs of the different versions. I'd like the unit tests and benchmarking to be ran on both versions of the library the easiest way possible.
This is just a variation of the method as given by #Michał Górny (I run out of comment space there)...
You could create an include file of the following form:
/* Automatically created file - do not edit or ugly dinosaur will eat you */
#ifndef PREFIX
# define RENAME(f)
#else
# define RENAME(f) PREFIX ## f
#endif
/* list all the function and variables you want to rename here in one place */
#define func_foo RENAME(func_foo)
#define func_bar RENAME(func_bar)
/* ... many more ... */
#undef RENAME
At least gcc allows you to specify the inclusion of a header file from command line with option -include rename.h (assuming this file is called rename.h). Because you use gcc lookalike options (-O3 and Os), I am assuming you use gcc in the rest of this answer. Otherwise, if your C compiler is reasonable, you should be able to do it in some similar way.
You can create easily two or even three versions of your library that can be linked in at the same time if you want, by providing different options for your C compiler (here through CFLAGS setting):
CFLAGS += -include rename.h -DPREFIX=fast_ -D_BUILD_FAST -O3 -DBENCHMARKING
CFLAGS += -include rename.h -DPREFIX=small_ -D_BUILD_SMALL -Os -DBENCHMARKING
CFLAGS += -D_BUILD_FAST -O2
If your library header files look very regular and if you declare the library private functions static, then it is easy to extract the functions from those header files by some dummy script using very simple regular expressions to automatically generate the rename.h file for you. This is a natural build target if you are using make or something similar. All the global variables also need to be renamed using the same method to allow simultaneous use.
There are three main points with this solution:
The ugly renaming business can be hidden in one file, you do not need to edit the actual source files - especially you do not need to clutter the source files but can keep them clean and easy to read.
The renaming can be easily automated, if you follow some simple principles (coding conventions followed for the header files and the header files will declare all the global variables and functions).
There is no reason to make benchmarking more cumbersome by needing to run your test program multiple times (this is relevant if you are as lazy as I am and dislike repetive tasks as violently as I do - I know many people do not care, it is somewhat a matter of preference).
One way would be: keep the same name for both and call appropriately depending on the compile time option set.
ifdef SMALL_FOO
void foo() {
/* Small foo code */
}
#endif
ifdef BIG_FOO
void foo() {
/* Big foo code */
}
#endif
Set the SMALL_FOO/BIG_FOO during compilation with -d.
As a quick solution, you can use macro to mangle the function name like:
#ifdef FAST
# define FUNC(x) FAST_##x
#else
# define FUNC(x) SLOW_##x
#endif
void FUNC(Foo)();
And now with -DFAST the library with FAST_Foo will be built; and without it, one with SLOW_Foo. Just note that you need to use the FUNC() macro in the implementation part as well (and whenever you are referring to that function from inside the library), and #ifdef FAST to switch between fast/slow code.
Just please don't use that in a production code.
If you attempt to link in both static libraries to the same executable, the second library listed in your link line will not have any effect, because all the symbols it provided was satisfied already by the first library. If you provided simple unique wrapper functions to call Foo, it would still fail, now because of multiple definitions. Here is an example:
/* x.c */
extern void Y_Bar ();
extern void Z_Bar ();
int main ()
{
Y_Bar();
Z_Bar();
}
This main calls unique wrapper functions, which are provided in liby.a and libz.a.
/* y.c in liby.a */
#include <stdio.h>
void Y_Bar () {
extern void Foo ();
Foo();
}
void Foo () {
printf("%s\n", "that Foo");
}
/* z.c in libz.a */
#include <stdio.h>
void Z_Bar () {
extern void Foo ();
Foo();
}
void Foo () {
puts("this foo");
}
Attempting to link the executable with -ly -lz will fail.
The easiest work around for you is to build two separate executables. Your benchmark driver could then execute both executables to compare their relative performance.
You say that you can build the library, changing the compile time options, so why not edit the code to change the names of the functions in each. (You'd be making two different versions of your library.)
Maybe you can use -D option when call gcc, like -D_FAST_, -D_SMALL_, or your can received a input parameter when using make, like use make CFG=FAST, make CFG=SMALL, in your makefile, you can define, when get parameterFAST, link to FAST library.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
What is the best solution to replace a new memory allocator in an existing code?
I'm writing a library in C. I'd like to know if there is a way to divert every malloc() call my library makes to a different "augmented" testmalloc() function that I provide without (significantly) modifying my library. This question is inspired from p158 of Kernighan and Pike's "The Practice of Programming", where they say
Write a version of your storage allocator that intentionally fails early, to test your code for recovering from out-of-memory errors.
I am in a position where I could provide a wrapper mymalloc() and use that exclusively in my library. I suspect it will be necessary to use this freedom to avoid multiple symbol definitions during linking.
yeah. you should include the library at last, and use #define malloc mymalloc
example:
library.h:
void * myalloc(int);
#define malloc myalloc
source.c:
#include <stdlib.h>
int* i = malloc(4);
-> uses myalloc
I guess writing your own malloc:
char* malloc(size_t sz)
{
return (char*)0;
}
and then linking it in doesn't work here?
(Background note: You can usually replace a function in a library with another by linking it in first in the link step. This doesn't replace the calls in the library, so the library still uses its own function, but everything that needed a link to malloc from your own code when the linker gets to your version will use your version.)
If you cannot modify the code you can consider using __malloc_hook.
See (http://www.gnu.org/s/libc/manual/html_node/Hooks-for-Malloc.html)
in addition to Yossarian's answer, you can use malloc hooks, defined at least for the GNU C library.
It is even possible to write a malloc() implementation that can succeed or fail depending on a global. Unix linkers won't look for the real malloc function as it finds one in the object file(s). I do not know how this would behave on Windows.
void *malloc(size_t aSize)
{
if (gNextMallocShallFail)
{
gNextMallocShallFail = 0; //--- next call will succeed
return NULL;
}
else
{
return realloc(NULL, aSize);
}
}