I package gnuradio for Mageia and we are having problems with test failures with 3.6.3 in our beta2 distro release. (from git tag v3.6.3 since release tarball was from 3.6.4git) We have boost-1.52 and the package builds, but fails 143 tests. Full build system log is here:- http://pkgsubmit.mageia.org/uploads/failure/cauldr... As a test I set up a local system using boost-1.53 beta1. (with uhd also built on the same system) This fails only 3 tests. log is here: http://mtf.no-ip.co.uk/pub/linux/barjac/soft/log.gnuradio Switching to boost-1.53 beta1 for us is not an option for a stable release, plus we are now in version freeze. Unless there is a fix for this using boost-1.52 then our only option may be to drop gnuradio from the distro. Any help will be appreciated. Barry
on 2013-01-23 11:43
on 2013-01-23 15:46
On Wed, Jan 23, 2013 at 5:42 AM, Barry Jackson <zen25000@zen.co.uk> wrote: > As a test I set up a local system using boost-1.53 beta1. (with uhd also > Any help will be appreciated. > > Barry > Barry, I'm afraid we can't use Boost 1.52 with GNU Radio. See: https://svn.boost.org/trac/boost/ticket/7669 The thread join_all is very important for clean operation of a flowgraph. There's a similar bug in 1.47 that we can't use, either. In fact, you shouldn't have been able to compile against 1.52 since we've explicitly disabled it in GrBoost.cmake. Is there an option of going back to 1.51? Tom
on 2013-01-23 15:59
On 01/23/2013 09:45 AM, Tom Rondeau wrote: >> 1358931665.ecosse.log<http://pkgsubmit.mageia.org/uploads/failure/cauldr... >> be to drop gnuradio from the distro. > > The thread join_all is very important for clean operation of a flowgraph. > There's a similar bug in 1.47 that we can't use, either. In fact, you > shouldn't have been able to compile against 1.52 since we've explicitly > disabled it in GrBoost.cmake. Has this been reported to the boost people? There is a boost 1.53 beta, I wonder if the problem is fixed there. Are the test failures related to the thread join_all problem? Philip > > Is there an option of going back to 1.51?
on 2013-01-23 16:02
On 01/23/2013 09:58 AM, Philip Balister wrote: > On 01/23/2013 09:45 AM, Tom Rondeau wrote: > > Has this been reported to the boost people? There is a boost 1.53 beta, > I wonder if the problem is fixed there. > There are two bug fixes related to join_all for 1.53. Any idea if they address the problem in gnuradio? http://www.boost.org/users/history/version_1_53_0.html Philip
on 2013-01-23 16:06
On Wed, Jan 23, 2013 at 9:58 AM, Philip Balister <philip@balister.org>wrote: > >> system log is here:- > http://mtf.no-ip.co.uk/pub/linux/barjac/soft/log.g... > >> > > Has this been reported to the boost people? There is a boost 1.53 beta, > I wonder if the problem is fixed there. > The link that I posted is to the Boost issue tracking system, so yes, it has been reported :) The ticket is closed as fixed, so it looks like 1.53 will work. > Are the test failures related to the thread join_all problem? > > Philip The test failures probably aren't related to this. This bug shows up by locking the entire program on exit, so the test would never complete. The failures are probably due to some mismatch in library versions or pre-built code. As I said, we don't allow GNU Radio to build with 1.52, so my guess it that cmake actually failed, but the Makefiles were still there from previous build attempts. Tom
on 2013-01-23 16:10
On Wed, Jan 23, 2013 at 10:01 AM, Philip Balister <philip@balister.org>wrote: > http://www.boost.org/users/history/version_1_53_0.html > > Philip > From what I'm reading, Boost 1.53 /should/ address our problem with the join_all. Unfortunately, they have also deprecated Mutex::scoped_lock, so we're going to have to reevaluate our use of that.... (not a show-stopper by any means, just some changes we'll have to make). Tom
on 2013-01-23 18:41
On Wed, Jan 23, 2013 at 7:08 AM, Tom Rondeau <tom@trondeau.com> wrote: > Unfortunately, they have also deprecated Mutex::scoped_lock, so we're > going to have to reevaluate our use of that.... (not a show-stopper by any > means, just some changes we'll have to make). > It looks like we are using the gruel::scoped_lock typedef everywhere except in the gr_file_source and gr::file_source blocks where bare boost::mutex::scoped_lock is used. I did a quick test of the below change to use the recommended type and at least all the QA unit tests pass: --- a/gruel/src/include/gruel/thread.h +++ b/gruel/src/include/gruel/thread.h @@ -31,7 +31,7 @@ namespace gruel { typedef boost::thread thread; typedef boost::mutex mutex; - typedef boost::mutex::scoped_lock scoped_lock; + typedef boost::unique_lock<boost::mutex> scoped_lock; typedef boost::condition_variable condition_variable; } /* namespace gruel */ So when the time comes it should be easy to switch over (and fix the bare usage in the file source.) Johnathan
on 2013-01-24 13:43
On 23/01/13 15:05, Tom Rondeau wrote: > >> > >> built on the same system) > >> > > The thread join_all is very important for clean operation of a > The link that I posted is to the Boost issue tracking system, so yes, it > The failures are probably due to some mismatch in library versions or > pre-built code. As I said, we don't allow GNU Radio to build with 1.52, > so my guess it that cmake actually failed, but the Makefiles were still > there from previous build attempts. > > Tom > I really don't know why the 1.52 build did not fail (without the tests). Our build system uses a clean minimal installation in chroot with only buildrequires installed, so nothing from previous builds can be left around. It was only a chance comment on irc that drew my attention to a possible problem. Using boost 1.53b1 (with or without the gruel/thread.h patch posted earlier) in a local build I see: 1 - qa_volk_test_all (Failed) 115 - qa_ctcss_squelch (Failed) 152 - qa_qtgui (Failed) Any clues as to the cause of these? Barry
on 2013-01-24 15:29
On Thu, Jan 24, 2013 at 7:42 AM, Barry Jackson <zen25000@zen.co.uk> wrote: >> >> failures with 3.6.3 in our beta2 distro release. >> failure/cauldron/core/release/**20130123090056.barjac.valstar.** >> **> >> >> Barry >> you >> has been reported :) >> pre-built code. As I said, we don't allow GNU Radio to build with 1.52, >> so my guess it that cmake actually failed, but the Makefiles were still >> there from previous build attempts. >> >> Tom >> >> > I really don't know why the 1.52 build did not fail (without the tests). > Our build system uses a clean minimal installation in chroot with only > buildrequires installed, so nothing from previous builds can be left around. > Strange. Cmake should fail with Boost not found. > > Barry > Could you run 'ctest -V -R <test name>' for these tests to see what they are? I wouldn't worry too much about the ctcss and qtgui failures. My OSX box has a problem with ctcss, too, though I've not gone to track it down since it's not a heavily used blocks. The qtgui is probably failing due to an issue with X. This will fail for me over ssh if I don't set things up correctly. The volk test is the most troubling, though. We definitely want that to pass. What's your processor? Tom
on 2013-01-25 17:12
On 24/01/13 14:28, Tom Rondeau wrote: > > Could you run 'ctest -V -R <test name>' for these tests to see what they > are? I wouldn't worry too much about the ctcss and qtgui failures. My > OSX box has a problem with ctcss, too, though I've not gone to track it > down since it's not a heavily used blocks. The qtgui is probably failing > due to an issue with X. This will fail for me over ssh if I don't set > things up correctly. > > The volk test is the most troubling, though. We definitely want that to > pass. I did these tests after re-building with boost-1.53b1 in a new clean chroot:- [baz@jackodesktop build]$ ctest -V -R qa_volk_test_all UpdateCTestConfiguration from :/home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/DartConfiguration.tcl Test project /home/baz/gnuradio/BUILD/gnuradio-3.6.3/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 1 Start 1: qa_volk_test_all 1: Test command: /home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/volk/lib/test_all 1: Test timeout computed to be: 9.99988e+06 1: /home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/volk/lib/test_all: error while loading shared libraries: libvolk.so.0.0.0: cannot open shared object file: No such file or directory 1/1 Test #1: qa_volk_test_all .................***Failed 0.02 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.29 sec The following tests FAILED: 1 - qa_volk_test_all (Failed) Errors while running CTest [baz@jackodesktop build]$ ls -l volk/lib/lib* lrwxrwxrwx 1 baz baz 16 Jan 25 15:12 volk/lib/libvolk.so -> libvolk.so.0.0.0 -rwxr-xr-x 1 baz baz 4603866 Jan 25 15:12 volk/lib/libvolk.so.0.0.0 [baz@jackodesktop build]$ ctest -V -R qa_ctcss_squelch UpdateCTestConfiguration from :/home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/DartConfiguration.tcl Test project /home/baz/gnuradio/BUILD/gnuradio-3.6.3/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 118 Start 118: qa_ctcss_squelch 118: Test command: /bin/sh "/home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/gr-analog/python/qa_ctcss_squelch_test.sh" 118: Test timeout computed to be: 9.99988e+06 118: .FF 118: ====================================================================== 118: FAIL: test_ctcss_squelch_002 (__main__.test_ctcss_squelch) 118: ---------------------------------------------------------------------- 118: Traceback (most recent call last): 118: File "/home/baz/gnuradio/BUILD/gnuradio-3.6.3/gr-analog/python/qa_ctcss_squelch.py", line 81, in test_ctcss_squelch_002 118: self.assertFloatTuplesAlmostEqual(expected_result, result_data, 4) 118: File "/home/baz/gnuradio/BUILD/gnuradio-3.6.3/gnuradio-core/src/python/gnuradio/gr_unittest.py", line 85, in assertFloatTuplesAlmostEqual 118: self.assertEqual (len(a), len(b)) 118: AssertionError: 39 != 34 118: 118: ====================================================================== 118: FAIL: test_ctcss_squelch_003 (__main__.test_ctcss_squelch) 118: ---------------------------------------------------------------------- 118: Traceback (most recent call last): 118: File "/home/baz/gnuradio/BUILD/gnuradio-3.6.3/gr-analog/python/qa_ctcss_squelch.py", line 106, in test_ctcss_squelch_003 118: self.assertFloatTuplesAlmostEqual(expected_result, result_data, 4) 118: File "/home/baz/gnuradio/BUILD/gnuradio-3.6.3/gnuradio-core/src/python/gnuradio/gr_unittest.py", line 87, in assertFloatTuplesAlmostEqual 118: self.assertAlmostEqual (a[i], b[i], places, msg) 118: AssertionError: 0.9 != 0.0 within 4 places 118: 118: ---------------------------------------------------------------------- 118: Ran 3 tests in 0.004s 118: 118: FAILED (failures=2) 1/1 Test #118: qa_ctcss_squelch .................***Failed 1.79 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 1.81 sec The following tests FAILED: 118 - qa_ctcss_squelch (Failed) Errors while running CTest [baz@jackodesktop build]$ ctest -V -R qa_qtgui UpdateCTestConfiguration from :/home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/DartConfiguration.tcl Test project /home/baz/gnuradio/BUILD/gnuradio-3.6.3/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 152 Start 152: qa_qtgui 152: Test command: /bin/sh "/home/baz/gnuradio/BUILD/gnuradio-3.6.3/build/gr-qtgui/python/qa_qtgui_test.sh" 152: Test timeout computed to be: 9.99988e+06 152: gri_fftw: /root/.gr_fftw_wisdom: Permission denied 152: gri_fftw: /root/.gr_fftw_wisdom: Permission denied 152: gri_fftw: /root/.gr_fftw_wisdom: Permission denied 152: .gri_fftw: /root/.gr_fftw_wisdom: Permission denied 152: . 152: ---------------------------------------------------------------------- 152: Ran 2 tests in 0.023s 152: 152: OK 1/1 Test #152: qa_qtgui ......................... Passed 1.24 sec The following tests passed: qa_qtgui 100% tests passed, 0 tests failed out of 1 Total Test time (real) = 1.25 sec > What's your processor? > Quad core all like this:- [baz@jackodesktop ~]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz stepping : 9 microcode : 0x12 cpu MHz : 1600.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 6860.16 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ----------------------snip---------------------
on 2013-01-25 17:30
On Fri, Jan 25, 2013 at 11:11 AM, Barry Jackson <zen25000@zen.co.uk> wrote: >> The volk test is the most troubling, though. We definitely want that to > gnuradio-3.6.3/build/**DartConfiguration.tcl > 1: Test timeout computed to be: 9.99988e+06 > > -rwxr-xr-x 1 baz baz 4603866 Jan 25 15:12 volk/lib/libvolk.so.0.0.0 > Ok, that's a problem. What does 'ldd test_all' say? It should link against libvolk.so.0.0.0, libboost_unit_test_framework, libstdc++, libc, libpthread, libm, and maybe some other linux-specific libs. The first is what we're looking for, obviously. > test 118 > ---------- > 118: > 118: File "/home/baz/gnuradio/BUILD/**gnuradio-3.6.3/gnuradio-core/** > 1/1 Test #118: qa_ctcss_squelch .................***Failed 1.79 sec > > 0% tests passed, 1 tests failed out of 1 > > Total Test time (real) = 1.81 sec > > The following tests FAILED: > 118 - qa_ctcss_squelch (Failed) > Errors while running CTest > That's the exact same error I get on my OSX box. I'll track it down soon. Ignore it for now. > test 152 > 152: ------------------------------**------------------------------** > > Total Test time (real) = 1.25 sec > Alright, so that fixed itself. > stepping : 9 > fpu_exception : yes > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > ----------------------snip----**----------------- > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > Ok, thanks. I was asking for the CPU info for VOLK, but looks like it's a more fundamental problem of finding the library than actually running it. Tom
on 2013-01-25 17:58
On 25/01/13 16:29, Tom Rondeau wrote:
> ldd test_all
[root@jackodesktop build]# cd volk/lib
[root@jackodesktop lib]# ldd test_all
linux-vdso.so.1 (0x00007fff67096000)
libvolk.so.0.0.0 => not found
libboost_unit_test_framework.so.1.53.0 =>
/lib64/libboost_unit_test_framework.so.1.53.0 (0x00007f9a2c6cf000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f9a2c3cc000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9a2c1b6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f9a2be04000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9a2bbe8000)
librt.so.1 => /lib64/librt.so.1 (0x00007f9a2b9e0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f9a2b6e2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9a2c98e000)
[root@jackodesktop lib]# ldconfig
[root@jackodesktop lib]# ldd test_all
linux-vdso.so.1 (0x00007fff7bdfe000)
libvolk.so.0.0.0 => not found
libboost_unit_test_framework.so.1.53.0 =>
/lib64/libboost_unit_test_framework.so.1.53.0 (0x00007f1e076c9000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f1e073c6000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f1e071b0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1e06dfe000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1e06be2000)
librt.so.1 => /lib64/librt.so.1 (0x00007f1e069da000)
libm.so.6 => /lib64/libm.so.6 (0x00007f1e066dc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e07988000)
The qtgui one that "fixed itself" still fails during the build, it only
passes when run manually.
I'm test building all our other packages that use boost in the hope that
there are no breakages with 1.53b1 - if that happens then I may have a
case for pushing for an update.
Barry
on 2013-01-25 18:07
On Fri, Jan 25, 2013 at 11:57 AM, Barry Jackson <zen25000@zen.co.uk> wrote: > On 25/01/13 16:29, Tom Rondeau wrote: > >> ldd test_all >> > > [root@jackodesktop build]# cd volk/lib > [root@jackodesktop lib]# ldd test_all > linux-vdso.so.1 (0x00007fff67096000) > libvolk.so.0.0.0 => not found > Unfortunately, this only confirms things but sheds no new light on the problem. Possibly a problem with the linker or cmake? > The qtgui one that "fixed itself" still fails during the build, it only > passes when run manually. > During build? You mean if you run "make test" (or just "ctest" with no arguments)? > I'm test building all our other packages that use boost in the hope that > there are no breakages with 1.53b1 - if that happens then I may have a case > for pushing for an update. > > Barry > Ok. Tom
on 2013-01-26 13:57
On 25/01/13 17:04, Tom Rondeau wrote: > > On Fri, Jan 25, 2013 at 11:57 AM, Barry Jackson <zen25000@zen.co.uk > <mailto:zen25000@zen.co.uk>> wrote: > > The qtgui one that "fixed itself" still fails during the build, it > only passes when run manually. > > > During build? You mean if you run "make test" (or just "ctest" with no > arguments)? Sorry - by "during build" I mean during rpm build using rpmbuild (which calls "make test" from the script it generates) I get: The following tests FAILED: 1 - qa_volk_test_all (Failed) 118 - qa_ctcss_squelch (Failed) 152 - qa_qtgui (Failed) Errors while running CTest make: *** [test] Error 8 error: Bad exit status from /home/baz/gnuradioOK/BUILDROOT/rpm-tmp.KRNdzY (%check) Whereas if I then cd into the build dir and issue "make test" or "ctest", I get: The following tests FAILED: 1 - qa_volk_test_all (Failed) 118 - qa_ctcss_squelch (Failed) Errors while running CTest > I'm test building all our other packages that use boost in the hope > that there are no breakages with 1.53b1 - if that happens then I may > have a case for pushing for an update. > No, we MUST now stay with 1.52, so maybe we could backport the relevent patches from boost-1.53 into our version of 1.52 ? The problem is finding the correct changes as I am not a programmer nor am I familiar with boost svn. Could anyone help in this? Thanks, Barry
on 2013-04-15 14:54
On 25/01/13 17:04, Tom Rondeau wrote: > Tom > OK it's been a long haul but we now have boost-1.53 in the distro and all build problems of other packages are fixed - just days before RC1 :) So I'm now back to looking at this ctest issue with gnuradio. I have attached the output from running ctest -V -R qa_volk_test_all from within the build system chroot by stopping it and dropping to the shell after the install stage. It still fails to find libvolk.so.0.0.0. As you will see I even cd'd into the dir and ran ./test_all from there. Do you have any clues? If the tests are skipped during package build and the resulting package is installed, there is no problem running volk_profile, so can we just ignore this test failure? It would be good to have all tests passing though ;) Barry
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.