For Axis2/C developers in linux platform valgrind is a indispensable tool. It helps you debug and profile your services and modules.
The gdb/valgrind is very powerful combination for debugging your applications in linux.
Before you use these tools make sure that you have built your applications and Axis2/C with debugging enabled. This is a simple check on seeing whether the configure.ac in Axis2/C root source folder has -g entry in CFLAGS as in
CFLAGS=”$CFLAGS -ansi -Wall -Werror -Wno-implicit-function-declaration -g -D_GNU_SOURCE”
You can debug Axis2/C clients by
valgrind ./echo 2> result
This will show any context errors associated with your client code. Context errors simply says that your code is broken at the specified places. If you need to further investigate these points you can use gdb with the specified source files line numbers. If you find zero context errors in your code then you are lucky. Then you can further investigate by
valgrind –leak-check=full ./echo 2> result
which show you all the memory leaks you have in your code. However this will hide the repetitions. To see them also you can use.
valgrind –leak-check=full –leak-resolution=high 2> result
You can debug server side similarly.
valgrind –leak-check=full ./axis2_http_server 2> result
or if you want to debug with Axis2/C apache module
valgrind –leak-check=full ./httpd -X 2> result
You can use result file to investigate on context errors and leaks as in the client side.
However there is a caveat when it comes debugging Axis2/C modules and Axis2/C services. valgrind could not show leaks in modules and services. I suspect this is because of dll loading libraries. The solution is to build your service/module statically with Axis2/C engine. Currently Axis2/C does not provide any facility to do this(I suggest this for future releases). So we need to do a small hack to get this done. I will explain here how I did the hack in order to debug Sandesha2/C module.
Say you need to debug your in flow path. I created the in handler header as following and put it in axis2c/src/core/engine folder
* @file sandesha2_sender.h
* @brief Sandesha Sender Interface
struct axis2_handler *handler,
const axutil_env_t *env,
struct axis2_msg_ctx *msg_ctx);
/** @} */
#endif /* SANDESHA2_IN_HANDLER_H */
Now go and include that file in phase.c file. Also add the following code into phase_invoke function
if(!axutil_strcmp(handler_name, “SandeshaGlobalInHandler”) || !axutil_strcmp(
“dam_handler_name %s. dam_phase_name %s”, handler_name, phase->name);
status = sandesha2_global_in_handler_invoke(phase->first_handler, env, msg_ctx);
status = sandesha2_in_handler_invoke(phase->first_handler, env, msg_ctx);
status = axis2_handler_invoke(handler, env, msg_ctx);
“Handler %s invoke failed within phase %s”, handler_name, phase->name);
Also link to sandesha2/C module library in the axis2c/src/core/engine/Makefile.am and don’t forget to include your module include files also there in.
That’s just the trick. Now you can build Axis2/C and your module and use valgrind as explained before.
At this point I would like to add that adding static module build support for Axis2/C is a great thing to do. Adding modules to Axis2/C is not a frequent phenomena. Actually we currently have only few modules like Rampart, Sandesha2/C and Savan/C. Making these statically built with Axis2/C might give us some performance advantage. We can give an Axis2/C configuration option to build certain standard modules statically with Axis2/C.
To do profiling Axis2/C modules/services with valgrind see previous entry here.