Tests fail building with boost1.52

GNU Radio
1

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/cauldron/core/release/20130123090056.barjac.valstar.22658/log/botcmd.1358931665.ecosse.log

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

2

On Wed, Jan 23, 2013 at 5:42 AM, Barry J. [email protected]
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

3

On 01/23/2013 09:45 AM, Tom R. wrote:

1358931665.ecosse.loghttp://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130123090056.barjac.valstar.22658/log/botcmd.1358931665.ecosse.log

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?

4

On 01/23/2013 09:58 AM, Philip B. wrote:

On 01/23/2013 09:45 AM, Tom R. 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

5

On Wed, Jan 23, 2013 at 9:58 AM, Philip B.
[email protected]wrote:

system log is here:-
http://mtf.no-ip.co.uk/pub/linux/barjac/soft/log.gnuradio>

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 :slight_smile:

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

6

On Wed, Jan 23, 2013 at 10:01 AM, Philip B.
[email protected]wrote:

Version 1.53.0

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

7

On 23/01/13 15:05, Tom R. 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

8

On Wed, Jan 23, 2013 at 7:08 AM, Tom R. [email protected] 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_lockboost::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

9

On Thu, Jan 24, 2013 at 7:42 AM, Barry J. [email protected]
wrote:

 >> failures with 3.6.3 in our beta2 distro release.

failure/cauldron/core/release/20130123090056.barjac.valstar.
**>
>> Barry
you
has been reported :slight_smile:
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 ’ 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

10

On Fri, Jan 25, 2013 at 11:11 AM, Barry J. [email protected]
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

11

On 24/01/13 14:28, Tom R. wrote:

Could you run 'ctest -V -R ’ 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® Core™ 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---------------------

12

On Fri, Jan 25, 2013 at 11:57 AM, Barry J. [email protected]
wrote:

On 25/01/13 16:29, Tom R. 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

13

On 25/01/13 17:04, Tom R. wrote:

On Fri, Jan 25, 2013 at 11:57 AM, Barry J. <[email protected]
mailto:[email protected]> 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

14

On 25/01/13 16:29, Tom R. 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

15

On 25/01/13 17:04, Tom R. 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 :slight_smile:

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 :wink:

Barry