Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
Daniel Burrows dburr...@debian.org (18/01/2010): It looks like the build succeeded on all the release architectures, so I think I might downgrade this so that aptitude can get into testing. (the version currently there is ancient and I don't really want it to be held up even further by problems on one of the experimental archs now that it seems to work everywhere else) No, it didn't. kfreebsd-* are release architectures… (The waitpid() issue still has to be investigated. But I see it also happens on other architectures, like amd64.) The waitpid() thing turned out to be mostly spurious; I've fixed it in head. I can't see how it would have caused a double-free, though. I didn't say it would have, my point was just about making sure it wasn't unnoticed. Mraw, KiBi. signature.asc Description: Digital signature
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
On Tue, Jan 19, 2010 at 10:44:08AM +0100, Cyril Brulebois k...@debian.org was heard to say: Daniel Burrows dburr...@debian.org (18/01/2010): It looks like the build succeeded on all the release architectures, so I think I might downgrade this so that aptitude can get into testing. (the version currently there is ancient and I don't really want it to be held up even further by problems on one of the experimental archs now that it seems to work everywhere else) No, it didn't. kfreebsd-* are release architectures… *boggle* All righty then. In that case, I'm going to disable the test cases on kfreebsd. It looks pretty clear to me from the transcript that the test case actually succeeded before crashing, which makes me suspect that it's the Boost test framework itself that's crashing, not aptitude code. This would not be the first time (Google for boost unit test double free); I'm beginning to think that this piece of Boost is not up to their usual quality, and I should consider dropping it and going back to cppunit, or just rolling my own :-/. (The waitpid() issue still has to be investigated. But I see it also happens on other architectures, like amd64.) The waitpid() thing turned out to be mostly spurious; I've fixed it in head. I can't see how it would have caused a double-free, though. I didn't say it would have, my point was just about making sure it wasn't unnoticed. No problem. Daniel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
On Tue, Jan 19, 2010 at 09:23:46AM -0800, Daniel Burrows wrote: All righty then. In that case, I'm going to disable the test cases on kfreebsd. It looks pretty clear to me from the transcript that the test case actually succeeded before crashing, which makes me suspect that it's the Boost test framework itself that's crashing, not aptitude code. This would not be the first time (Google for boost unit test double free); I'm beginning to think that this piece of Boost is not up to their usual quality, and I should consider dropping it and going back to cppunit, or just rolling my own :-/. I also had many discussions with the author of Boost.Test in the past and I even remember discussions related to this error on lists. IIRC the patch https://svn.boost.org/trac/boost/changeset/56467 or the patch in https://svn.boost.org/trac/boost/ticket/3432 fixes it. If you use the header only version of the test you do not even need to rebuild Boost once you changed framework.ipp. Could you test this patch? Using a recent version of Boost (less than 4 months old) could also fix this problem. Jens -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
Package: src:aptitude
Version: 0.6.1.4-1
Severity: serious
Justification: FTBFS
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
your package FTBFS on kfreebsd-i386 due to testsuite issues:
| /usr/bin/make check-TESTS
| make[2]: Entering directory
`/srv/storage/kibi/hack/porting-4/aptitude-0.6.1.4/tests'
| {(T(30): {Install(b v2)}), (T(75): {Install(a v1),
Install(b v2)}), (T(100): {Install(a v1 source: a v2 -? {})}), (T(125):
{Break(b v2 -? {c v2})}), (T(125, 10): {Install(c v3), Break(b v2 -? {c
v2})})}
| {, (T(30): {Install(b v2)}), (T(75): {Install(a v1), Install(b v2)}),
(T(100): {Install(a v1 source: a v2 -? {})}), (T(125): {Break(b v2 -? {c
v2})}), (T(125, 10): {Install(c v3), Break(b v2 -? {c v2})})}
| .{(T(30): {Install(b v2)}), (T(75): {Install(a v1), Install(b v2)}), (T(100):
{Install(a v1 source: a v2 -? {})}), (T(125): {Break(b v2 -? {c v2})}),
(T(125, 10): {Install(c v3), Break(b v2 -? {c v2})})}
| {, (T(30): {Install(b v2)}), (T(75): {Install(a v1), Install(b v2)}),
(T(100): {Install(a v1 source: a v2 -? {})}), (T(125): {Break(b v2 -? {c
v2})}), (T(125, 10): {Install(c v3), Break(b v2 -? {c v2})})}
| .{(T(30): {Install(b v2)}), (T(75): {Install(a v1), Install(b v2)}), (T(100):
{Install(a v1 source: a v2 -? {})}), (T(125): {Break(b v2 -? {c v2})}),
(T(125, 10): {Install(c v3), Break(b v2 -? {c v2})})}
| {, (T(30): {Install(b v2)}), (T(75): {Install(a v1), Install(b v2)}),
(T(100): {Install(a v1 source: a v2 -? {})}), (T(125): {Break(b v2 -? {c
v2})}), (T(125, 10): {Install(c v3), Break(b v2 -? {c v2})})}
| .30298 [0x400] ERROR aptitude.resolver.hints.parse null - Invalid
hint : expected an action, but found nothing.
| 30299 [0x400] ERROR aptitude.resolver.hints.parse null - Invalid hint 823:
expected a target, but found nothing.
| 30299 [0x400] ERROR aptitude.resolver.hints.parse null - Invalid hint badact
target: the action badact should be approve, reject, or a number.
| 30299 [0x400] ERROR aptitude.resolver.hints.parse null - Invalid hint
approve ?version(423 1234): invalid target: Match pattern ends unexpectedly
(expected ')').
| 30299 [0x400] ERROR aptitude.resolver.hints.parse null - Invalid hint
approve ?version(3425: invalid target: Match pattern ends unexpectedly
(expected ')').
| .30315 [0x400] WARN aptitude.temp null - Ignoring the second attempt
to initialize the temporary file module.
| F
|
|
| !!!FAILURES!!!
| Test Results:
| Run: 56 Failures: 1 Errors: 0
|
|
| 1) test: TempTest::testShutdownOnExit (F) line: 368 test_temp.cc
| forced failure
| - waitpid() failed: No child processes
|
|
| .
|
|
| OK (56 tests)
|
|
| PASS: cppunit_test
| Running 30 test cases...
|
| *** No errors detected
| *** glibc detected *** ./boost_test: double free or corruption (!prev):
0x080c1298 ***
| /bin/sh: line 4: 38199 Aborted ${dir}$tst
| FAIL: boost_test
| ===
| 1 of 2 tests failed
| ===
| make[2]: *** [check-TESTS] Error 1
Full build logs:
https://buildd.debian.org/status/package.php?suite=unstablep=aptitude
Mraw,
KiBi.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
Weird thing is: I get the same failure, but it doesn't kill the build. It should. So by my count that's two bugs here :-/. Daniel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
Ah, I got fooled by some garbage printed by the cppunit test. The actual problem is the double-free in the Boost tester. D'oh. Daniel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
OK, I can't see any sign of a double-free in either valgrind or libefence, which are usually pretty good about catching this sort of thing. Can you run something similar on FreeBSD and see what it says? Thanks, Daniel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
Daniel Burrows dburr...@debian.org (18/01/2010): OK, I can't see any sign of a double-free in either valgrind or libefence, which are usually pretty good about catching this sort of thing. Can you run something similar on FreeBSD and see what it says? Sorry for the delay… (we just started building experimental as well) Quick checks: (to run in the tests directory after a build) = - no valgrind on kfreebsd-* - libefence results in: | $ LD_PRELOAD=libefence.so.0.0 ./boost_test | | Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens. | Running 30 test cases... | | *** No errors detected | Bus error - turning on debugging leads to… a successful test: | $ ./boost_test --debug | Running 30 test cases... | […] | *** No errors detected - to reproduce the initial issue: | $ ./boost_test | Running 30 test cases... | | *** No errors detected | *** glibc detected *** ./boost_test: double free or corruption (!prev): 0x080c1298 *** | Aborted I've asked some folks on #-kbsd to keep an eye on this bug in case they have some time to track it down. Hopefully you'll hear from one of us soonish. Mraw, KiBi. signature.asc Description: Digital signature
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
Cyril Brulebois k...@debian.org (19/01/2010): I've asked some folks on #-kbsd to keep an eye on this bug in case they have some time to track it down. Hopefully you'll hear from one of us soonish. Hrm, this is strange. Given my previous observations about --debug, I tried adding a cout call (cout foo endl;) before and after ::configure(), and added a iostream include and using namespace std accordingly. No more double free. I removed those cout calls, keeping only #include and using namespace, no more double free. Only keeping the #include line is sufficient, I can't reproduce this issue double free issue. (The waitpid() issue still has to be investigated. But I see it also happens on other architectures, like amd64.) Mraw, KiBi. signature.asc Description: Digital signature
Bug#565736: aptitude: FTBFS on kfreebsd-i386: testsuite failure
On Tue, Jan 19, 2010 at 03:32:36AM +0100, Cyril Brulebois k...@debian.org was heard to say: Only keeping the #include line is sufficient, I can't reproduce this issue double free issue. Weird. It looks like the build succeeded on all the release architectures, so I think I might downgrade this so that aptitude can get into testing. (the version currently there is ancient and I don't really want it to be held up even further by problems on one of the experimental archs now that it seems to work everywhere else) (The waitpid() issue still has to be investigated. But I see it also happens on other architectures, like amd64.) The waitpid() thing turned out to be mostly spurious; I've fixed it in head. I can't see how it would have caused a double-free, though. One of the tests is supposed to fork a child and check that its temporary files get deleted when it calls exit() (testing an atexit handler). I forgot to write explicit code for the child process in the switch, so it tried to wait on PID 0, then continued running tests -- that's what the failure message is from. The parent's test succeeded, although it wasn't really testing the behavior it was supposed to test. Daniel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
