[OSM-dev] Osmium: may I help with development?
johannes.kolb.lists at gmail.com
Mon Jul 29 14:01:12 UTC 2013
2013/7/24 Jochen Topf <jochen at remote.org>
> thanks for your work. I have just accepted your pull request. One tiny
> When running the tests under valgrind I don't see the output of valgrind
> more, so can't check it. Hm, maybe if valgrind isn't happy the Makefile
> it as a test failure and outputs everything? I haven't check that.
You are right, valgrind output doesn't show, even if it reports errors. In
fact I didn't use valgrind, so I didn't notice. You have to pass an extra
"--error-exitcode=1" to valgrind, then valgrind errors count as a failed
I also noticed a memory leak in the test t/osmfile/read_and_write.cpp which
I wrote. I'll send a pull request with the change.
As I noticed, still not all errors are reported. It seems, that blocks
"possibly lost" and "still reachable" don't count as real errors for
Exactly these are the complaints valgrind has with one of my test
functions. I comment it out for the moment.
I added the option "-o" to run_tests.sh, which shows the test output
> How is the code coverage stuff supposed to be understood? I see lots of
> warnings from system include files etc. Not sure how to interpret all that.
There are two coverage targets: make coverage generates nice HTML pages
with a coverage report using lcov. I didn't find an easy way to exclude
system headers in this tool, so it shows too much files. I am sure this can
make coverage-gcov annotates the .hpp files with coverage information. This
tool has an option to restrict it to "relative" includes, so it only shows
the relevant header files.
Both reports have to be read with a grain of salt. Unfortunately the tools
can't distinguish between lines which are commented out and functions which
are never executed. So even if it says 100% coverage, this means only 100%
coverage of the functions called. See also
As I understand it the coverage percentage is worthless, only the detailed
reports can help to identify the missing tests.
> Maybe you can check the "clean" targets of the Makefiles in the main and
> directory. They now both do some cleanup of test stuff, but not properly.
O, I forgot to update these. As I see, the clean target misses the coverage
reports and the files tests.info, test_main, tests. Is it ok, if the
Makefile in main calls the Makefile in test recursively for the "clean"
> There is one line in test/Makefile that seems to make no sense:
> PROBLEMS = t/geometry t/tags
> Maybe a leftover from some tests.
This is correct, I deleted the line.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev