PendingMessages member variable of APT's GlobalError class initializes as "true" with -std=c++11
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
gcc-4.7 (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Symptoms: If a program using libapt-pkg is compiled with -std=c++11 with gcc 4.7 (this used to work in gcc 4.6), APT's global GlobalError class[1] (accessible via the macro "_error" in any file that includes apt-pkg/error.h) always returns "true" when the PendingError() member is called. This happens directly after the GlobalError instance is created, so there is no chance for libapt-pkg to have put anything on the error stack. Calling Discard() or DumpErrors() does not clear the flag, and none of the functions that print the errors to stdout actually print anything. (Presumably, the error stack really is empty)
This behavior is not present when compiling an application with -std=c++11 with gcc 4.6, and the issue goes away if compiled without the c++11 cxxflag with gcc 4.7.
The impact is fairly severe. The libqapt library utilizes c++11 features in its source code, so this effectively breaks the qaptworker runtime utility from running any sort of apt transaction (Cache update, commit) due to the fact that it can't check for errors reliably, and will error out immediately due to the detected "error". This, in effect, breaks the Muon Suite (Kubuntu's default package manager.) which uses libqapt (and the qaptworker) for running apt tasks that require administrative access. For this reason I'm assigning the bug priority for this report to "high".
I've attached a (very) small Minimally Reproducible Testcase along with a small build script that should aid in making testing this bug convenient. The test case prints "error!" if the bug is present, and will return silently if everything is working as it should.
[1]http://
Changed in gcc-4.7 (Ubuntu): | |
milestone: | quantal-alpha-1 → quantal-alpha-2 |
Changed in apt (Ubuntu): | |
milestone: | quantal-alpha-1 → quantal-alpha-2 |
Changed in apt (Ubuntu): | |
milestone: | quantal-alpha-2 → quantal-alpha-3 |
I can confirm this as long as APT isn't build with the -std=c++11 flag, too. [0]
The boolean is properly initialized in the (only) constructor to false, so this doesn't make that much sense.
[0] It fails to build currently, but the fix is simple: obj/methods/ http.o :SendReq( pkgAcqMethod: :FetchItem* , CircleBuf&)’: obj/methods/ http.o] Fehler 1
Compiling http.cc to ../build/
http.cc: In member function ‘void HttpMethod:
http.cc:761:41: error: unable to find string literal operator ‘operator"" PACKAGE_VERSION’
make[1]: *** [../build/
Just add spaces around the constant - the c++11 standard requires it. (same for https.cc)
After these two fixes APT builds happily (tested on debian gcc4.7.0-8) - also it's testcases which are executed at buildtime: test/libapt/ globalerror_ test.cc which doesn't fail, so everything seems to be fine then.