[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault



severity 952464 important
thanks

In data lunedì 24 febbraio 2020 21:10:53 CET, Paul Gevers ha scritto:
> Source: clazy
> Version: 1.6-2
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian-ci@lists.debian.org
> User: debian-ci@lists.debian.org
> Usertags: flaky

The test is not flaky.

> Dear maintainer(s),
> 
> With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
> failed on arm64 in testing when that autopkgtest was run with the binary
> packages of gcc-10 from unstable.

The failures have nothing to do with gcc-10.

> I looked into the history of your autopkgtest and it fails very often.

Err, not really, no need to exagerate things that are not like that.

The situation is more complex than that, and it needs a longer
explanation. No TL;DR is provided.

clazy is a clang plugin to detect more issues in Qt-based software,
and because of that it uses (and links to) the LLVM/clang libraries.
What is shipped is the following:

(1) /usr/bin/clazy
(2) /usr/bin/clazy-standalone
(3) /usr/lib/MULTI-ARCH/ClazyPlugin.so

(3) is the actual plugin, which is used like:
  $ clang -Xclang -load -Xclang ClazyPlugin.so -Xclang \
      -add-plugin -Xclang clazy [etc...]
This is links to the LLVM and clang libraries.

(2) is a similar version of (1), made as standalone executable rather
than a compiler plugin. It is used as compiler, so e.g.:
  $ clazy [...]

(1) is a shells script that wraps the usage of (3), with extra
parameters for version/help, and list the actual checks available.

clazy supports various LLVM versions (clazy 1.6 requires LLVM >= 5),
and it is generally updated whenever a new LLVM version is released.
For this reason, I let it built with the default LLVM version (that is
src:llvm-defaults), so using the unversioned llvm/clang -dev packages.
OTOH, (1) as shipped upstream calls the unversioned "clang++"
executable: because of this, we have local changes that record the path
to the clang++ tool of the clang version used during the built (i.e.
the Debian default one). It is easy to check this:

  $ dpkg -l | grep clazy
  ii  clazy                           1.6-2+b1          amd64        Clang plugin for additional warnings
  $ grep CLANGXX /usr/bin/clazy
      ${CLANGXX:-/usr/lib/llvm-9/bin/clang++} --version | head -1 | awk '{printf("clang version: %s\n",$3)}'
    ${CLANGXX:-/usr/lib/llvm-9/bin/clang++} -Qunused-arguments -Xclang -load -Xclang $ClazyPluginLib -Xclang -add-plugin -Xclang clazy $ExtraClangOptions "$@"

In addition to that, the clang-X package used is recorded as dependency:

  $ apt-cache show clazy | grep Depends
  Depends: libc6 (>= 2.14), libllvm9 (>= 1:9~svn298832-1~), libstdc++6 (>= 9), clang-9

So clazy pulls whichever version of clang it was built with, and thus
(1) works OOTB.

Now let's take a look at the autopkgtest structure:

  $ cat debian/tests/control 
  Tests: run-tests
  Depends: @, clang, clang-tools, python3, qtbase5-dev, qtdeclarative5-dev
  Restrictions: rw-build-tree, allow-stderr

  $ cat debian/tests/run-tests 
  #!/bin/sh
  
  set -e
  
  # show some facts about clang/clang++, so it is easier to debug issues
  clang -E -x c - -v < /dev/null
  clang++ -E -x c++ - -v < /dev/null
  
  cd tests
  ./run_tests.py --verbose

The upstream tests/run_tests.py executable executes the tests twice:
with (2) and (3). We can understand easily that the tests with (2) work
fine in all the cases, and indeed they pass flawlessy. The tests with
(3) use "clang++" as compiler name by default, and as such it is the
Debian default.

Putting all the pieces together: why the autopkgtest can fail?
The answer is simple: the version of src:llvm-defaults in the
environment of the test is different than the one used to build clazy.

In this particular case: clazy was rebuilt when src:llvm-defaults was
switched from 8 to 9, and because LLVM 9 was already in testing, the
binNMU migrated instantly to testing. However, src:llvm-defaults took
its 5 days to migrate to testing, so "clang" was still 8.
I see src:llvm-defaults migrated to testing today: this means that the
failures "disappear", since in both suites the versions of
(a) src:llvm-defaults used when building clazy
(b) src:llvm-defaults present
are the same.

What I will not do: switch away from the unversioned llvm version.
This means manually changing the used llvm version, which is a PITA,
and generally not needed for what clazy needs.

It seems like run_tests.py allows changing the "clang" executable used
with the CLANGXX environment variable. This seems a promising move,
however detecting what was the clang version used to build clazy only
by looking at the installed clazy seems hard. I will try to come up
with something in the next days to allow testing with the right
version. Although, as I said, the issue "fixed itself" until the next
src:llvm-defaults switch, this is slightly less problematic.

In the meanwhile: because of what I said above, I'm demoting the
severity of this bug to important. Also, Paul, please re-enable the
autopkgtest of clazy on ci.debian.net, as they will pass now.

Thanks,
-- 
Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: