ceedling memory Leak with valgrind under current docker container

[georgemichalis]

Hello.
Before anything else i have to say that ceedling is a great tool, and i am using it for a few years now.
I am also using it to unit test some things for an esp-idf project, and i had made a docker file that includes ceeling and ruby but it was build on ubuntu.

Today i wanted to test something really quick, and i used the provided docker file instead of my own. The provided docker file is based on alpine.

with the valgrind enabled in the project file running any test results in a memory leak. At the beginning i though that i indeed had a memory leak, but then i tried newly created empty tests files that only have the automatically generated code.

This is the resulting output:

File test/test_GL_NameOf.c created
Generate Complete
/project # ceedling test:GL_NameOf


Test 'test_GL_NameOf.c'
-----------------------
Generating runner for test_GL_NameOf.c...
Compiling test_GL_NameOf_runner.c...
Compiling test_GL_NameOf.c...
Compiling GL_NameOf.c...
Linking test_GL_NameOf.out...
Running Hook pre_test_fixture_execute...
==85== Memcheck, a memory error detector
==85== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==85== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==85== Command: build/test/out/test_GL_NameOf.out
==85==
==85==
==85== HEAP SUMMARY:
==85==     in use at exit: 468 bytes in 4 blocks
==85==   total heap usage: 5 allocs, 1 frees, 508 bytes allocated
==85==
==85== 16 bytes in 2 blocks are still reachable in loss record 1 of 3
==85==    at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==85==    by 0x4059055: ??? (in /lib/ld-musl-x86_64.so.1)
==85==
==85== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==85==    at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==85==    by 0x4059055: ??? (in /lib/ld-musl-x86_64.so.1)
==85==    by 0xD66C9B84AEA8A325: ???
==85==    by 0x742F646C697562C6: ???
==85==    by 0x2F74756F2F747364: ???
==85==    by 0x5F4C475F74736573: ???
==85==    by 0x6F2E664F656D614D: ???
==85==    by 0x365F363878007474: ???
==85==
==85== 420 bytes in 1 blocks are still reachable in loss record 3 of 3
==85==    at 0x48A16F2: calloc (vg_replace_malloc.c:762)
==85==    by 0x4058E1D: ??? (in /lib/ld-musl-x86_64.so.1)
==85==    by 0x4059A70: __dls3 (in /lib/ld-musl-x86_64.so.1)
==85==    by 0xD66C9B84AEA8A325: ???
==85==    by 0x742F646C697562C6: ???
==85==    by 0x2F74756F2F747364: ???
==85==    by 0x5F4C475F74736573: ???
==85==    by 0x6F2E664F656D614D: ???
==85==    by 0x365F363878007474: ???
==85==
==85== LEAK SUMMARY:
==85==    definitely lost: 0 bytes in 0 blocks
==85==    indirectly lost: 0 bytes in 0 blocks
==85==      possibly lost: 0 bytes in 0 blocks
==85==    still reachable: 468 bytes in 4 blocks
==85==         suppressed: 0 bytes in 0 blocks
==85==
==85== For lists of detected and suppressed errors, rerun with: -s
==85== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
ERROR: Shell command failed.
> Shell executed command:
'valgrind --track-origins=yes --leak-check=full --show-leak-kinds=all --errors-for-leak-kinds=all --error-exitcode=10 build/test/out/test_GL_NameOf.out'
> Produced output:
test_GL_NameOf.c:17:test_GL_NameOf_NeedToImplement:IGNORE: Need to Implement GL_NameOf

and this is the project file

---

# Notes:
# Sample project C code is not presently written to produce a release artifact.
# As such, release build options are disabled.
# This sample, therefore, only demonstrates running a collection of unit tests.
# type >ceedling module:create[FileName]

:project:
  :use_exceptions: FALSE
  :use_test_preprocessor: TRUE
  :use_auxiliary_dependencies: TRUE
  :build_root: build
#  :release_build: TRUE
  :test_file_prefix: test_
  :which_ceedling: gem
  :ceedling_version: 0.31.1
  :default_tasks:
    - test:all

#:test_build:
#  :use_assembly: TRUE

#:release_build:
#  :output: MyApp.out
#  :use_assembly: FALSE

:environment:

:extension:
  :executable: .out
  #:source: .cpp


:paths:
  :test:
    - +:test/**
    - -:test/support
  :source:
    - main/**
  :support:
    - test/support
  :libraries: []

:defines:
  # in order to add common defines:
  #  1) remove the trailing [] from the :common: section
  #  2) add entries to the :common: section (e.g. :test: has TEST defined)
  :common: &common_defines []
  :test:
    - *common_defines
    - TEST
  :test_preprocess:
    - *common_defines
    - TEST

:cmock:
  :treat_externs: :include
  :mock_prefix: mock_
  :when_no_prototypes: :warn
  :enforce_strict_ordering: TRUE
  :plugins:
    - :ignore
    - :callback
    - :return_thru_ptr
    - :array
    - :expect_any_args
    - :ignore_arg
  :treat_as:
    uint8:    HEX8
    uint16:   HEX16
    uint32:   UINT32
    int8:     INT8
    bool:     UINT8

:unity: #great big gorilla processor that grunts and scratches
  :defines:
    - UNITY_SUPPORT_64 

# Add -gcov to the plugins list to make sure of the gcov plugin
# You will need to have gcov and gcovr both installed to make it work.
# For more information on these options, see docs in plugins/gcov
:gcov:
  :utilities:
    #- ReportGenerator
    - gcovr
  :reports:
    - HtmlDetailed
    - Text
    - JSON
  :gcovr:
    :html_medium_threshold: 75
    :html_high_threshold: 90

# :tools:
# Ceedling defaults to using gcc for compiling, linking, etc.
# As [:tools] is blank, gcc will be used (so long as it's in your system path)
# See documentation to configure a given toolchain for use
:tools:
  :pre_test_fixture_execute:
    :executable: valgrind
    :arguments:
      - --track-origins=yes
      - --leak-check=full
      - --show-leak-kinds=all
      - --errors-for-leak-kinds=all
      - --error-exitcode=10
      - ${1}

# LIBRARIES
# These libraries are automatically injected into the build process. Those specified as
# common will be used in all types of builds. Otherwise, libraries can be injected in just
# tests or releases. These options are MERGED with the options in supplemental yaml files.
:libraries:
  :placement: :end
  :flag: "-l${1}"
  :path_flag: "-L ${1}"
  :system: []    # for example, you might list 'm' to grab the math library
  :test: []
  :release: []

:plugins:
  :load_paths:
    - "#{Ceedling.load_path}"
  :enabled:
    - stdout_pretty_tests_report
    - module_generator
    - xml_tests_report
    - gcov
    - command_hooks
:flags:
  :test:
    :compile:
      :*:
      - -UNITY_INCLUDE_DOUBLE
...

The same exact test and project file can be used under an ubuntu docker install with the tests successful

The docker file that i am using is the following (it may have a few extra packages because it has been recommissioned from a much more complicated dockerfile). Obviously the resulting image is way larger (because of ubuntu) than the alpine one (1.2Gb vs 300Mb)

FROM ubuntu:20.04

#skip confirmations
ARG DEBIAN_FRONTEND=nointeractive

# install the requirements for qemu, unity and ruby
#qemu
RUN apt-get update \
  && apt install -y -q \
  cmake \
  curl \
  python3 \
  python3-pip\
  unzip\
  zip\
  wget \
  git \
  hwdata \
  libglib2.0-0 \
  libnuma1 \
  libpixman-1-0 \
  linux-tools-virtual

#unity tools
RUN apt install -y -q \
  coreutils \
  gcc \
  gcovr \
  valgrind \
  libc-dev

#rbenv
RUN apt install -y -q \
  autoconf \
  bison \
  patch \
  build-essential \
  rustc \
  libssl-dev \
  libyaml-dev \
  libreadline-dev \
  zlib1g-dev \
  libgmp-dev \
  libncurses5-dev \
  libffi-dev \
  libgdbm6 \
  libgdbm-dev \
  libdb-dev \
  && rm -rf /var/lib/apt/lists/*


RUN update-alternatives --install /usr/local/bin/usbip usbip `ls /usr/lib/linux-tools/*/usbip | tail -n1` 20

ENV LC_ALL=C.UTF-8
ENV LANG=C.UTF-8



# download and install rbenv
RUN git clone https://github.com/sstephenson/rbenv.git ~/.rbenv \
&&  echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc \
&&  echo 'eval "$(rbenv init -)"' >> ~/.bashrc \
&&  echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.zshrc \
&&  echo 'eval "$(rbenv init -)"' >> ~/.zshrc \
&&  export PATH="$HOME/.rbenv/bin:$PATH"

#  install ruby build
RUN git clone https://github.com/rbenv/ruby-build.git "$HOME/.rbenv/plugins/ruby-build"
RUN ~/.rbenv/bin/rbenv install 2.7.2
RUN ~/.rbenv/bin/rbenv global 2.7.2



COPY assets/gems /assets/gems

# Install Ceedling, CMock, Unity
RUN set -ex \
 # Prevent documentation installation taking up space
  echo -e "---\ngem: --no-ri --no-rdoc\n...\n" > .gemrc \
  # Install Ceedling and related gems
  && /root/.rbenv/shims/gem install --force --local /assets/gems/*.gem \
  # Cleanup
  && rm -rf /assets \
  && rm .gemrc


CMD ["/bin/bash"]

If you want to use it feel free, or let me know and i can do a PR to include this in the repo.

[mkarlesky]

Hello, @georgemichalis. So sorry for taking a while to get back to you. We have been deep into preparing and releasing a massive Ceedling 1.0.0 release now available (in fact, the 1.0.1 bug fix release will be available soon).

With the big deal 1.0.0 release of Ceedling also comes a sizable upgrade to the Docker images as well. They are now based on a well-patched and minimal version of Debian instead of Alpine. This means all the most commonly available tooling, libraries, etc. instead of the musl variants that Alpine uses. There's now 4 versions of the Docker images — with and without plugin tools and gcc or gcc-arm-none-eabi as the core toolchain. In addition, each image is targeted to run natively as either amd64 or arm64 on the Docker host. This means that all 4 Docker images run on either Intel or ARM host machines (in this sense, there's really 8 images total). If you go to the Docker Hub page you'll see the 4 images and tags for 1.0.0 (and a coming revision). Since you're already a Docker user, this is the easiest way to get a hold of the new Ceedling.

With this I want to convey a few important points:

1. The existing Docker image is superseded as is the 0.31.1 version of Ceedling itself. All attention and resources are being invested in the new images and new version of Ceedling. I'd actually suggest you wait for the 1.0.1 release of both Ceedling and the Docker images as a number of important bugs have been found and fixed.
2. I'd encourage you to try Valgrind with the new tooling and Docker images. If there are obvious problems because of Ceedling bugs or insufficient support in the Docker images, we'll want to fix that rather than look at the old Docker image. I'd recommend starting with Ceedling’s Release Notes in order to do so. The Release Notes link to all the other new and improved documentation and also include a cheat sheet to help users update their project configuration files to new features and conventions.
3. We do hope to eventually release a Valgrind Ceedling plugin or incorporate Valgrind support directly into Ceedling (similar to how gdb support is now built-in to automatically highlight the source of test crashes).

Updated docs for this repository and in Docker Hub are trailing the rest of the work. I apologize for that.