Code Coverage of Service Using Shared Library

ChurroLocoChurroLoco Member Andy CookOrganization: WMSProject: Casino Back End Servers
Ice Version: 3.4.1
Compiler: GCC 4.4.3
OS: Linux (Ubuntu 10.04)
Coverage Tool: gcov

I am currently trying to run code coverage analysis during our integration tests. So I instrumented the shared libraries used by our ICE services by using the g++ flags below.
-fprofile-arcs -ftest-coverage

and I link in the following library when the (.so) file is generated.
-lgcov


To make sure I had the coverage process correct I made my on test that dynamically linked the instrumented (.so) files, and it successfully generated the (.gcda) files.

However when the ICE service uses the instrumented .so file no (.gcda) file is generated.

Does anyone have any experience running code coverage analysis on ICE services while they are running using gcov?

Comments

  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Hi Andy,

    It's my understanding that gcov embeds the absolute pathname of the .gcda file into each instrumented .o file, which you can confirm with a quick test:

    strings -a myprogram | grep gcda

    So unless you change the output directory (by using the GCOV_PREFIX and GCOV_PREFIX_STRIP environment variables), the .gcda files will be created in the same directory as the original .o files.

    Are you saying that the .gcda files are not being created in the expected directory?

    It's still not clear to me whether this problem is related to Ice. If you're still having trouble, please provide more information about exactly what you're trying to do. For example, are you instrumenting a standalone executable that's linked with Ice? Your own IceBox service in a separate shared library? Or perhaps an Ice-supplied service? Were you also trying to instrument the Ice libraries, or only your own code?

    Regards,
    Mark
  • ChurroLocoChurroLoco Member Andy CookOrganization: WMSProject: Casino Back End Servers
    I have checked the .so files and the instrumentation path declared in the strings is the expected path.
    For example, are you instrumenting a standalone executable that's linked with Ice? Your own IceBox service in a separate shared library? Or perhaps an Ice-supplied service?

    To clarify, we are making our own shared libraries (.so files) that inherit from IceBox::Service and are loaded by the IceBox. The service does successfully start, and we able to perform integration tests using a separate client. So the instrumented (.so) files are definitely being loading and used, but no .gcda file are being generated at the location indicated be the path indicated in the strings.

    Also, we have made sure the location is read/writable by all and tried deploying as root user just in case it was an issue of permissions, but that doesn't seem to be the case.
    Were you also trying to instrument the Ice libraries, or only your own code?
    We are only trying to get coverage analysis of our shared library.
  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Hi,

    I was about to suggest that you try re-compiling the icebox executable with the gcov options, in case the output was only generated if the executable itself was built that way.

    However, I first decided to try it myself on CentOS 5.5 and found it wasn't necessary. I built the Ice 3.4.1 source distribution using the default configuration. Next, inside the cpp/demo/IceBox/hello subdirectory, I modified the Makefile to include this setting:

    CXXFLAGS += -fprofile-arcs -ftest-coverage

    After running make clean; make in this directory, I started IceBox as follows:

    % icebox --Ice.Config=config.icebox

    After shutting the server down, I found the following files were created:

    cpp/demo/IceBox/hello/Hello.gcda
    cpp/demo/IceBox/hello/HelloI.gcda
    cpp/demo/IceBox/hello/HelloServiceI.gcda

    I don't know why it's not working in your case, but I thought I should describe my experience in case it was helpful.

    Regards,
    Mark
  • ChurroLocoChurroLoco Member Andy CookOrganization: WMSProject: Casino Back End Servers
    Thanks,

    I'll see if I can recreate your results. If I can, I'll try to see what is different between building our service and the 'hello' demo.
  • ChurroLocoChurroLoco Member Andy CookOrganization: WMSProject: Casino Back End Servers
    So I was able to recreate your results and succesfully run coverage of the "hello" demo, but on inspection I noticed we are doing things a little differently. The hello demo compiles into two executables (server and client), we are running an icebox server that runs a few IceBox services as dynamically linked shared libraries, not executables.

    Are there any examples that demonstrate this? We would like to try to get coverage of just those shared libraries that are icebox services in themselves.
  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Hi,

    I was actually using the IceBox version of our hello demo (demo/IceBox/hello) for my test. Give that a try and see how it goes.

    Regards,
    Mark
  • ChurroLocoChurroLoco Member Andy CookOrganization: WMSProject: Casino Back End Servers
    Well, that works too... I guess the next major difference is that our IceBox is running on an IceGrid. I guess I'll try and start this IceBox with IceGrid in the same manner that we do.

    BTW Thanks for your help so far.
  • ChurroLocoChurroLoco Member Andy CookOrganization: WMSProject: Casino Back End Servers
    I guess a good start would be the IceGrid hello sample :)
Sign In or Register to comment.