Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on ppc64el
where it succeeded until somewhere before 2025-01-23. Can you please
investigate the situation and fix it? I copied some of the output at the
bottom of this report.

The release team has documented [1] that failing autopkgtest on amd64
and arm64 are considered RC in testing as well as regressions on all
release architectures.

More information about this bug and the reason for filing it can be
found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://release.debian.org/testing/rc_policy.txt

https://ci.debian.net/packages/c/cppcheck/unstable/ppc64el/58666087/

621s TestValueFlow::valueFlowSafeFunctionParameterValues
621s TestValueFlow::valueFlowUnknownFunctionReturn
621s TestValueFlow::valueFlowUnknownFunctionReturnRand
621s TestValueFlow::valueFlowUnknownFunctionReturnMalloc
621s TestValueFlow::valueFlowPointerAliasDeref
621s TestValueFlow::valueFlowCrashIncompleteCode
621s TestValueFlow::valueFlowCrash
621s Segmentation fault

tag 1099986 + help
thanks

Update:

I've been unable to reproduce the crash on platti (testing and sid).

In testing the autopkgtest fails since the upload of gcc-14 14.2.0-14:
https://ci.debian.net/packages/c/cppcheck/testing/ppc64el/
For sid there is less data, but a matching date range:
https://ci.debian.net/packages/c/cppcheck/unstable/ppc64el/

With the help of Antonio Terceiro I was able to extract a stacktrace from the
crash in the autopkgtest environment (full stacktrace attached):

#0  0x000000010d81e9e4 in std::__cxx11::_List_base<...>::_M_clear
(this=0x7ffff20ba358) at /usr/include/c++/14/bits/list.tcc:74
#1  std::__cxx11::_List_base<...>::~_List_base (this=0x7ffff20ba358,
__in_chrg=<optimized out>) at /usr/include/c++/14/bits/stl_list.h:576
#2  std::__cxx11::list<...>::~list (this=0x7ffff20ba358, __in_chrg=<optimized
out>) at /usr/include/c++/14/bits/stl_list.h:904
#3  ValueFlow::Value::~Value (this=0x7ffff20ba310, __in_chrg=<optimized out>) at
./lib/vfvalue.h:43
#4  0x000000010ddd85ac in TestValueFlow::valueFlowCrash
(this=this@entry=0x137c95460) at ./test/testvalueflow.cpp:7386
#5  0x000000010ddded70 in TestValueFlow::run (this=0x137c95460) at
./test/testvalueflow.cpp:148
#6  0x000000010d149718 in TestFixture::run (this=this@entry=0x137c95460, str="")
at ./test/fixture.cpp:355
#7  0x000000010d149ef8 in TestFixture::runTests (args=...) at ./test/fixture.cpp:395
#8  0x000000010d12d70c in main (argc=<optimized out>, argv=<optimized out>) at
./test/main.cpp:42

But I have no idea how to proceed from here.

For completeness: I've also run the test suite with valgrind. There is a
repeated report about "conditional jump or move depends on uninitialized
value(s)". The location is lib/vfvalue.h:163, but as far as I can see that
member is always initialized from lib/vfvalue.h:317. The reports occur before
and after the crash location, but I don't see any direct connection.

Note for debugging: the test case is build/bin/testrunner. The number of tests
can be reduced by replacing the GLOB for srcs at the top of
tests/CMakeLists.txt with

set(srcs "testvalueflow.cpp;fixture.cpp;helpers.cpp;main.cpp;options.cpp")

(Used for valgrind with higher --num-callers value, I did not verify whether
that still triggers the crash in the autopkgtest environment.)

Hi ppc64el porters,

cppcheck has an autopkgtest regression on ppc64el (see #1099986 for details).
Any help would he highly appreciated.

Best regards,
   Joachim

P.S: I'm not subscribed, please keep the bug (or me) on CC:.

I tried to debug this with a qemu image from
https://people.debian.org/~gio/dqib/, but failed to reproduce the issue.

For those worrying about their favorite reverse dependency of cppcheck showing
up on the autoremovals list: unless someone comes up with a way to reproduce/fix
this, I plan to downgrade the severity given that (a) there are no reports that
cppcheck itself does not work on ppc64el, (b) it is not reproducible except in
the autopkgtest framework/machine, and (c) the low relative popularity of
ppc64el compared to other architectures.

   Joachim

Hi,

* Joachim Reichel [Sat Apr 05, 2025 at 11:49:43AM +0000]:

I reached out to the release team how we should handle this. The way
to handle this for now seems to be to not run the test on ppc64el
(or exit 77 (with skippable restriction) on ppc64el). I implemented
this at https://salsa.debian.org/reichel/cppcheck/-/merge_requests/2

Then we can reduce the severity of this issue and no longer have
this as RC bug for now.

Joachim, could you please take care of submitting my MR and upload a
new package version?

regards
-mika-

tags 1099986 - pending patch
severity 1099986 normal
thanks


The patch has been applied in 2.17.1-2:

=====
cppcheck (2.17.1-2) unstable; urgency=medium

    * Disable autopkgtests on ppc64el, thanks to Michael Prokop (see #1099986).
=====

Best regards,
   Joachim