genhtml 2.2 memory usage regression

[jschueller]

hi,

the recent update to version 2.2 absolutely blows up my memory (I can see a quick 70%/32gb spike then my computer stops responding)

I'm using it to generate reports for a medium-large c++/Python library on an archlinux vm

reproducing it can requires a bit of time to run the test-suite:

FROM openturns/archlinux-base
MAINTAINER jschueller
WORKDIR /tmp
RUN sudo pacman -Syu swig lapack libxml2 mold lcov ceres-solver nlopt boost eigen --noconfirm
RUN git clone --depth 1 https://github.com/openturns/openturns.git
RUN cd openturns && cmake -DCMAKE_INSTALL_PREFIX=~/.local \
      -DCMAKE_UNITY_BUILD=ON -DCMAKE_UNITY_BUILD_BATCH_SIZE=32 \
      -DCMAKE_C_FLAGS="--coverage" -DCMAKE_CXX_FLAGS="--coverage -fuse-ld=mold" \
      -DSWIG_COMPILE_FLAGS="-O1" -DUSE_TBB=OFF .
RUN cd openturns && make OT -j16 && make install -j12
RUN cd openturns && ctest -E "cppcheck|Factory" -R "Distribution|Function" --output-on-failure -j12 --repeat after-timeout:2 --schedule-random
# RUN sudo pacman -S python swig cmake lapack libxml2 git --noconfirm
RUN cd openturns && gcov `find lib/src/ -name "*.gcno"`
RUN cd openturns && lcov --capture --directory . --output-file coverage.info --include "*.cxx"
RUN cd openturns && genhtml --output-directory coverage coverage.info

this is adapted from my actual CI scripts:
https://github.com/openturns/openturns/blob/master/.ci_support/run_docker_coverage.sh

if I revert back to 2.1 the memory stays <6%:

sudo pacman -U https://archive.archlinux.org/packages/l/lcov/lcov-2.1-1-any.pkg.tar.zst --noconfirm

[henry2cox]

I guess it is the lcov --capture ... part where you see the problem. Can you run that with --profile - which will keep track of some performance statistics, so we can see what is happening. I would not expect to see systematically increased memory requirements. What class of machine are you using? How many cores, how much memory?

What is in your .lcovrc? Have you enabled --parallel execution? Are you using any throttling?
How large is medium/large? (Amongst other projects, we build llvm - which is about 800K LOC, no idea how many files and not sure how many testsuites.)

[jschueller]

• I double checked its definetely the genhtml command, and it seems this one has no --profile option
• looking at the logs it seems to choke processing a very large generated swig source c++ file with 77k lines, thats probably a good hint
• I'm using a linux vm with 4 cpu / 16 gb ram on remote but also tried locally with 16cpu / 32 gb ram which should be plenty
• I dont have any config files everything is set from command line, no --parallel but I'm definetely checking this out if it can speed up the build
• if you think llvm then its medium I guess (270k loc for the c++ lib part only)

[henry2cox]

Sorry - missed your genhtml .. command - was fixated on the capture above it.

Can you check which version of lcov you have installed - and specifically which genhtml you are getting?
Recent ones all support --profile - so if yours complains about an unknown parameter, you definitely aren't getting the right one.
It could be that you have a bad PERL5LIB and are picking up some very old lcovutil.pm - but I would be very surprised if that was happening and you didn't see all kinds of other issues.

77K LOC is a lot - but not unprecedented. I would not have expected a huge issue.
(removed speculation about a possible issue related to tooltips...but tooltip is not generated without annotation - so that is not the issue.)

That said: I guess that this file is generated code, and I seriously doubt that you care about whether it is exercised or not (do you write or generate tests to test all of it?)
If this is true, then you probably want to exclude it anyway - as that code is 25% of your project, and is just obscuring the numbers you actually care about.

[henry2cox]

To verify our speculation around the suspect large file, you could run genhtml twice:

• genhtml --profile -o includeHuge --include '*hugefile.c' mydata.info
• genhtml --profile -o excludeHuge --exclude '*hugefile.c mydata.info`

If the first runs badly and the second better...then we have confirmed our suspicion.

After confirming, if you run yet again after adding the -v flag to increase verbosity: the log might tell us more about what is happening/what is going wrong. Verbosity makes things slower - so might not be viable.
It is also worth watching your HTML output directory - where that file's sourceview is written - to see whether the output is generated, is gowing, and what it appears to be doing.
If there is no source generated yet...then the issue is likely in some of the preprocessing steps.

Adding parallelism will somewhat complicate the debugging - as the order things get processed will not be deterministic - however, the child that croaks should be the huge file, assuming that our speculation is correct.

If this is an opensource/public project: it would likely help to attach a tarball of that source file and the captured .info for it.
Then we could reproduce the issue (or not) and see about fixing it.
If it is a proprietary project...would need to think of alternatives.

[henry2cox]

I generated a fake example and ran with my sandbox genhtml

$ /usr/bin/time -f '%E %M' ../../lcov/bin/genhtml -o x output.info --profile
Reading tracefile output.info.
Found 2 entries.
Found common filename prefix "/home/hcox/sample"
Generating output.
Processing file sample/main.c
  lines=1002 hit=1002 functions=1 hit=1
Processing file sample/src/func0.c
  lines=78000 hit=40000 functions=1000 hit=1000
Overall coverage rate:
  source files: 2
  lines.......: 51.9% (41002 of 79002 lines)
  functions...: 100.0% (1001 of 1001 functions)
Message summary:
  no messages were reported
0:11.44 906052 0

Seems not to not exhibit problems.

I think I need more information, to reproduce your issue.