Bug#1071219: apt: debListParser fails to parse arch lists with extraneous whitespace: terminate called after throwing an instance of 'std::length_error'
Package: apt
Version: 2.9.2
Severity: serious
one package to reproduce this bug is mpich 4.2.0-5.1
mpich-4.2.0# apt-get build-dep -y .
Note, using directory '.' to get the build dependencies
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_M_create
Aborted (core dumped)
Running this through gdb and extracting the interesting part of the
backtrace:
#11 0x00007ffff7e28c6c in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<char const*, void> (__a=...,
__end=0x5555555baade " amd64 powerpc armhf],\n"...,
__beg=0x5555555baadf "amd64 powerpc armhf],\n"..., this=0x7fffffffd670) at /usr/include/c++/13/bits/basic_string.h:765
#12 debListParser::ParseDepends (Start=<optimized out>,
Start@entry=0x5555555baabb "valgrind [i386 arm64 ppc64el ppc64 amd64 powerpc armhf],\n"...,
Stop=Stop@entry=0x5555555bab15 "\nBuild-Conflicts: libamdhip64-dev\n"..., Package=..., Ver=..., Op=@0x7fffffffd930: 0, ParseArchFlags=<optimized out>, StripMultiArch=<optimized out>, ParseRestrictionsList=<optimized out>, Arch=...) at ./apt-pkg/deb/deblistparser.cc:667
Note the double space in ..."ppc64 amd64"...
It tries to create a std::string with __end < __beg resulting in a
negative (or insane) length.
The nasty thing is that the error only happens if there has been no
match, yet. I.e on amd64 ..."amd64 ppc64el"... would *not* have
caused the error.
I'm not sure how to build a test string that reliably works on all
architectures...
Anyway, apt should be able to parse the following string correctly:
"Build-Depends: foobar [ i386 armhf armel amd64 ] , blah [ !arm64 !x32 !amd64 ] , baz"
not sure if it is allowed to inject spaces between '!' and arch as in
..." ppc64 ! mips64el ! s390x "...
(I noticed this due to the salsa-ci failure while building mpich)
e.g. https://salsa.debian.org/science-team/mpich/-/jobs/5731958
Andreas
PS: This will probably be "fixed" in mpich 4.2.0-6
Reply to: