Forum: GNU Radio make test failure at qa_constellation_receiver

E5215f0bc7dc90e3ba544ceedb895cd0?d=identicon&s=25 Alick Zhao (Guest)
on 2012-04-13 08:53
(Received via mailing list)
Attachment: test.f16.log (2 KB)
Attachment: test.t41.log (2 KB)
Attachment: test.t60.log (2 KB)
Hi all,

Recently I have upgraded my gnuradio build to v3.5.3 on several
computers, and I find that on two machines with Ubuntu 11.10, make test
will fail the test qa_constellation_receiver while on the other two with
Fedora 16 all tests are passed.

To investigate the problem, I add one line in the file
`gr-digital/python/qa_constellation_receiver.py` which just print the
value of constellation, differential, and correct before the assert.
Then I run the script
`build/gr-digital/python/qa_constellation_receiver_test.sh`. The output
is recorded and attached below. Among them:

* test.t41.log is from a Thinkpad T41 with Ubuntu 11.10 32bit installed,
* test.t60.log is from a Thinkpad T60 with Ubuntu 11.10 32bit installed,
* test.f16.log is from a HP 6531s with Fedora 16 x86_64 installed.

Hope these logs are helpful to diagnose the problem.

PS: As a side note, my debugging line's output appears later than the
result, which is not the case for screen output. I think this is
probably related to stdout buffering.

PS2: I once changed the REQ_CORRECT to 0.7 on one Ubuntu machine,
and then made the test passed. I wonder if it is a valid fix.

alick
A86d989af06c5372bdb7bb1d30d703cf?d=identicon&s=25 Ben Reynwar (Guest)
on 2012-04-13 17:43
(Received via mailing list)
2012/4/12 Alick Zhao <alick9188@gmail.com>:
> Then I run the script
> result, which is not the case for screen output. I think this is
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

Weird.  This test is probabilistic (not ideal really) but the chance
of it failing due to chance should be very small.  If it's
consistently failing on one machine but not another then there's
something fishy going on, and lowering REQ_CORRECT, while making the
test pass, wouldn't help finding what's causing the problem.

First thing I'd do would be to repeat the test a bunch of times and
confirm you're getting a consistently higher BER on one computer than
another.  Then I'd do a complete uninstall and reinstall of gnuradio
on a computer having the issue.  If the problem is still there then
it's probably going to be an unpleasant bug to find.

Has anybody else seen this?

Cheers,
Ben
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2012-04-13 20:37
(Received via mailing list)
On Fri, Apr 13, 2012 at 11:41 AM, Ben Reynwar <ben@reynwar.net> wrote:
>> value of constellation, differential, and correct before the assert.
>> PS: As a side note, my debugging line's output appears later than the
>> Discuss-gnuradio@gnu.org
> confirm you're getting a consistently higher BER on one computer than
> another. Then I'd do a complete uninstall and reinstall of gnuradio
> on a computer having the issue. If the problem is still there then
> it's probably going to be an unpleasant bug to find.
>
> Has anybody else seen this?
>
> Cheers,
> Ben


Alick,

I had seen that before, but it was a virtual machine installation of
11.10, 32-bit. I pinged Ben about it, but he didn't see same results
with a native install of 32-bit 11.10. I couldn't track down where the
problem was occurring or why, so I chalked it up to a problem with the
VM system.

Again, is anyone else having an issue like this? It appears to be
something really sneaky since most of the qa_constellation tests pass
with exactly the same numbers and results as they are expected to but
1 or 2 strangely deviate.

Thanks,
Tom
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (Guest)
on 2012-04-13 20:37
(Received via mailing list)
On Fri, Apr 13, 2012 at 08:41:41AM -0700, Ben Reynwar wrote:
> it's probably going to be an unpleasant bug to find.
>
> Has anybody else seen this?

Yep, I've seen this--works on my Desktop, doesn't work on my Atom
netbook. Both Ubuntu. However, I thought this bug was squashed a while
ago. I'll dig out my netbook this weekend and see if it still occurs.

MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
A86d989af06c5372bdb7bb1d30d703cf?d=identicon&s=25 Ben Reynwar (Guest)
on 2012-04-13 22:20
(Received via mailing list)
2012/4/12 Alick Zhao <alick9188@gmail.com>:
> Then I run the script
> result, which is not the case for screen output. I think this is
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

It sounds like this is definitely a bug, but it's hard for me to track
it down because I can't replicate it.  Does the bug still occur if you
set FREQUENCY_OFFSET = 0 in the test case?
E5215f0bc7dc90e3ba544ceedb895cd0?d=identicon&s=25 Alick Zhao (Guest)
on 2012-04-14 11:21
(Received via mailing list)
Attachment: ctest.log.46 (3 KB)
Attachment: do_repeat_test (213 Bytes)
On Fri, 13 Apr 2012 13:20:01 -0700, Ben Reynwar wrote:
>> value of constellation, differential, and correct before the assert.
>> PS: As a side note, my debugging line's output appears later than the
>> result, which is not the case for screen output. I think this is
>> probably related to stdout buffering.
>>
>> PS2: I once changed the REQ_CORRECT to 0.7 on one Ubuntu machine,
>> and then made the test passed. I wonder if it is a valid fix.
>>
>
> It sounds like this is definitely a bug, but it's hard for me to track
> it down because I can't replicate it.  Does the bug still occur if you
> set FREQUENCY_OFFSET = 0 in the test case?

Yes the bug still occurs.

I just wrote a simple script to ran the test for 50 times on T60 with
Ubuntu, GNU Radio 3.5.3 equipped, before and after FREQUENCY_OFFSET set
to 0. All failed the test. (n_pass is 0/50 in both sets) Every test's
output is almost identical in each set except particular test time
length. The ones before FREQUENCY_OFFSET change is basically the same as
test.t60.log already attached. One of the ones with FREQUENCY_OFFSET set
to 0 is attached below. I guess the almost same contents of output is
due to fixed random seed.

I also ran the script on a Dell desktop with Fedora, and the result is
50/50 pass the test. Then I notice one line in the qa python file says
that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell
desktop.

alick
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (Guest)
on 2012-04-14 13:41
(Received via mailing list)
On Sat, Apr 14, 2012 at 05:20:13PM +0800, Alick Zhao wrote:
>
> I also ran the script on a Dell desktop with Fedora, and the result is
> 50/50 pass the test. Then I notice one line in the qa python file says
> that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell
> desktop.

So,

I tried this on a native 32-Bit Ubuntu 11.10, and it fails (tells me
it's using "Volk machine: sse3_32".

I also noticed the line that says seed=1234 fails. Also, the seed is set
multiple times in the script. If this is the source of the bug or not,
it should be fixed, because the seed is reset somewhere in the guts of
the test. I'll post a patch on patch-gnuradio--this eliminates the
problem on my machine, for some reason. If it does the same for you,
this might actually be the solution.

MB


--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2012-04-14 18:25
(Received via mailing list)
On Sat, Apr 14, 2012 at 04:40, Martin Braun <martin.braun@kit.edu>
wrote:

> I'll post a patch on patch-gnuradio--this eliminates the
> problem on my machine, for some reason. If it does the same for you,
> this might actually be the solution.

This was applied on 3.5.3 maint and 3.6.0git master.

Johnathan
E5215f0bc7dc90e3ba544ceedb895cd0?d=identicon&s=25 Alick Zhao (Guest)
on 2012-04-14 18:40
(Received via mailing list)
On Sat, 14 Apr 2012 13:40:35 +0200, Martin Braun wrote:
>> due to fixed random seed.
>
> I also noticed the line that says seed=1234 fails. Also, the seed is set
> multiple times in the script. If this is the source of the bug or not,
> it should be fixed, because the seed is reset somewhere in the guts of
> the test. I'll post a patch on patch-gnuradio--this eliminates the
> problem on my machine, for some reason. If it does the same for you,
> this might actually be the solution.
>
> MB
>
>

I applied the patch and tested it. No failure, yeah!

However, with my debugging line, I can see this:

[...]
constellation: <constellation psk (m=32)>  differential: True  correct:
0.942307692308
constellation: <constellation psk (m=64)>  differential: True  correct:
0.772435897436
constellation: <constellation psk (m=2)>  differential: True  correct:
1.0
[...]

So why 0.77XXX on the second line does not cause the assert to fail?

alick
A86d989af06c5372bdb7bb1d30d703cf?d=identicon&s=25 Ben Reynwar (Guest)
on 2012-04-15 07:14
(Received via mailing list)
It appears that each test case is being run twice.  I think once to
generate the xml output, and once to generate output for stdout and
tell you whether it failed.  The random number generator isn't being
reseeded at the start of each test so they can produce different
results, so you can sometimes see debug statements that indicate it
should fail, but the output to stdout claims that is passes.  I've
attached a patch that make each test use it's own random number
generating object which seems a tidier way to do this, and makes the
tests repeatable.

Since there seem to be a fair number of choices of seed that produce
an error fraction of over 0.2, I've also increased the acceptable
error rate in the test to 0.3, as Alick initially suggested.
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2012-04-15 07:33
(Received via mailing list)
On Sat, Apr 14, 2012 at 22:13, Ben Reynwar <ben@reynwar.net> wrote:

> I've
> attached a patch that make each test use it's own random number
> generating object which seems a tidier way to do this, and makes the
> tests repeatable.

This will have to wait until morning, but I'll get this on maint and
master.

Johnathan
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2012-04-15 23:48
(Received via mailing list)
On Sun, Apr 15, 2012 at 1:13 AM, Ben Reynwar <ben@reynwar.net> wrote:
> Since there seem to be a fair number of choices of seed that produce
> an error fraction of over 0.2, I've also increased the acceptable
> error rate in the test to 0.3, as Alick initially suggested.

Hey Ben and Martin,

Both patches have been applied. It fixed the issues on my 32-bit VM,
too, so it looks like we got it.

Thanks for help!

Tom
E5215f0bc7dc90e3ba544ceedb895cd0?d=identicon&s=25 Alick Zhao (Guest)
on 2012-04-16 05:15
(Received via mailing list)
On Sat, 14 Apr 2012 22:13:50 -0700, Ben Reynwar wrote:

> Since there seem to be a fair number of choices of seed that produce
> an error fraction of over 0.2, I've also increased the acceptable
> error rate in the test to 0.3, as Alick initially suggested.
>

Issue solved too. Thanks all for your help!

alick
60246db32e812ad421f3c65d7c4287ee?d=identicon&s=25 Curt Karnstedt (Guest)
on 2013-08-22 16:29
(Received via mailing list)
I'm building gnuradio (version 3.7.0) for the first time, and the
qa_constellation receiver test failed.  I am building in a CentOS 6.4
64-bit
virtual machine, running on an Lenovo Y500.   What can I do to help
debug?



I 171/172 Test #171: qa_fcd ...........................   Passed    0.16
sec
        Start 172: qa_classify
172/172 Test #172: qa_classify ......................   Passed    0.32
sec

99% tests passed, 1 tests failed out of 172

Total Test time (real) =  82.56 sec

The following tests FAILED:
  143 - qa_constellation_receiver (Failed)
Errors while running CTest
make: *** [test] Error 8




--
View this message in context:
http://gnuradio.4.n7.nabble.com/make-test-failure-...
Sent from the GnuRadio mailing list archive at Nabble.com.
D3e3c5e41e9aed486856802be823e181?d=identicon&s=25 Johnathan Corgan (Guest)
on 2013-08-22 22:32
(Received via mailing list)
On Thu, Aug 22, 2013 at 7:27 AM, Curt Karnstedt
<ckarnstedt@gmail.com>wrote:

>
> I'm building gnuradio (version 3.7.0) for the first time, and the
> qa_constellation receiver test failed.  I am building in a CentOS 6.4
> 64-bit
> virtual machine, running on an Lenovo Y500.   What can I do to help debug?
>

Try:

$ ctest -V -R qa_constellation_receiver

...to output the failure information.
60246db32e812ad421f3c65d7c4287ee?d=identicon&s=25 Curt Karnstedt (Guest)
on 2013-08-22 23:11
(Received via mailing list)
[curt@localhost build]$ ctest -V -R qa_constellation_receiver
UpdateCTestConfiguration  from
:/home/curt/Downloads/gnuradio-3.7.0/build/DartConfiguration.tcl
Start processing tests
UpdateCTestConfiguration  from
:/home/curt/Downloads/gnuradio-3.7.0/build/DartConfiguration.tcl
Test project /home/curt/Downloads/gnuradio-3.7.0/build
Constructing a list of tests
Done constructing a list of tests
Changing directory into
/home/curt/Downloads/gnuradio-3.7.0/build/volk/lib
...
Changing directory into
/home/curt/Downloads/gnuradio-3.7.0/build/gr-digital/python/digital
143/172 Testing qa_constellation_receiver
Test command: /bin/sh
/home/curt/Downloads/gnuradio-3.7.0/build/gr-digital/python/digital/qa_constellation_receiver_test.sh
Test timeout computed to be: 9.99988e+06
Traceback (most recent call last):
  File
"/home/curt/Downloads/gnuradio-3.7.0/gr-digital/python/digital/qa_constellation_receiver.py",
line 174, in <module>
    gr_unittest.run(test_constellation_receiver,
"test_constellation_receiver.xml")
  File
"/home/curt/Downloads/gnuradio-3.7.0/gnuradio-runtime/python/gnuradio/gr_unittest.py",
line 135, in run
    os.makedirs(path, 0750)
  File "/usr/lib64/python2.6/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: './.unittests/python'
-- Process completed
***Failed
Changing directory into
/home/curt/Downloads/gnuradio-3.7.0/build/gr-atsc/lib
...
Changing directory into
/home/curt/Downloads/gnuradio-3.7.0/build/gr-wavelet/python/wavelet

0% tests passed, 1 tests failed out of 1

The following tests FAILED:
    143 - qa_constellation_receiver (Failed)
Errors while running CTest
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (CEL) (Guest)
on 2013-08-22 23:36
(Received via mailing list)
On Thu, Aug 22, 2013 at 04:10:47PM -0500, Curt Karnstedt wrote:
> gr_unittest.py", line 135, in run
>     os.makedirs(path, 0750)
>   File "/usr/lib64/python2.6/os.py", line 157, in makedirs
>     mkdir(name, mode)
> OSError: [Errno 13] Permission denied: './.unittests/python'
> -- Process completed
> ***Failed

I haven't seen this specific error before, but did you do a 'sudo make'
by
accident anywhere? Perhaps chown-ing your build dir might help.

MB


--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
60246db32e812ad421f3c65d7c4287ee?d=identicon&s=25 Curt Karnstedt (Guest)
on 2013-08-23 00:23
(Received via mailing list)
Yes, thanks.  Somehow some of the files in the source had root
ownership.
 I changed ownership, re-built, and then got a different error message.
So
I am starting the build from scratch again. Will let you know.
60246db32e812ad421f3c65d7c4287ee?d=identicon&s=25 Curt Karnstedt (Guest)
on 2013-08-23 01:10
(Received via mailing list)
Here are the results.  I get a segfault, same as the last time after I
fixed the ownership.

[curt@localhost build]$ ctest -V -R qa_constellation_receiver
UpdateCTestConfiguration  from
:/home/curt/Downloads/gnuradio-3.7.0/build/DartConfiguration.tcl
Start processing tests
UpdateCTestConfiguration  from
:/home/curt/Downloads/gnuradio-3.7.0/build/DartConfiguration.tcl
Test project /home/curt/Downloads/gnuradio-3.7.0/build
Constructing a list of tests
Done constructing a list of tests
Changing directory into
/home/curt/Downloads/gnuradio-3.7.0/build/volk/lib
...
Changing directory into
/home/curt/Downloads/gnuradio-3.7.0/build/gr-digital/python/digital
143/172 Testing qa_constellation_receiver
Test command: /bin/sh
/home/curt/Downloads/gnuradio-3.7.0/build/gr-digital/python/digital/qa_constellation_receiver_test.sh
Test timeout computed to be: 9.99988e+06
/home/curt/Downloads/gnuradio-3.7.0/build/gr-digital/python/digital/qa_constellation_receiver_test.sh:
line 7: 33977 Segmentation fault      (core dumped) /usr/bin/python -B
/home/curt/Downloads/gnuradio-3.7.0/gr-digital/python/digital/qa_constellation_receiver.py
-- Process completed
***Failed
Changing directory into
/home/curt/Downloads/gnuradio-3.7.0/build/gr-atsc/lib
...
Changing directory into
/home/curt/Downloads/gnuradio-3.7.0/build/gr-wavelet/python/wavelet

0% tests passed, 1 tests failed out of 1

The following tests FAILED:
    143 - qa_constellation_receiver (Failed)
Errors while running CTest
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-08-23 16:27
(Received via mailing list)
On Thu, Aug 22, 2013 at 7:09 PM, Curt Karnstedt <ckarnstedt@gmail.com>
wrote:
> Constructing a list of tests
> line 7: 33977 Segmentation fault      (core dumped) /usr/bin/python -B
> 0% tests passed, 1 tests failed out of 1
>
> The following tests FAILED:
>     143 - qa_constellation_receiver (Failed)
> Errors while running CTest

Granted the constellation_receiver QA code is one of the more complex
tests we have, I've never heard of it segfaulting before.

Can you just run 'ctest -V -R constellation_receiver' again, maybe a
couple of times, to see if it always segfaults and if it provides more
detailed information about what's going on?

--
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
60246db32e812ad421f3c65d7c4287ee?d=identicon&s=25 Curt Karnstedt (Guest)
on 2013-08-23 17:11
(Received via mailing list)
After running some of the python scripts were listed in error message in
the tracebacks, I ran the test again, and it passed.  It's like either
some
dependency or library got built or loaded after I was fooling around.
Test
the theory, I rebuilt everything from scratch in a separate directory.
 However, all the tests passed the first go around.  But then after
tinkering a bit more, and running the unittest in the fresh build again,
it
failed  (the one that just passed).  I have't figured out what is going
on.
 I'm not a software person, but I am curious about this.  I did a 'make
install' after I got all the unittests pass (before it failed again), so
I
"think" I have a working GnuRadio with a constellation_receiver now.
I'll
try running again later.
2bf444db9eb21e09279aa2b6557861de?d=identicon&s=25 ibmsorcerer (Guest)
on 2014-01-05 03:29
(Received via mailing list)
I built gnuradio 3.7.2.1 from scratch on a SuSE Linux Enterprise Server
11
with SP3 running as a VM.

I ran into this problem with the constellation_receiver test.

bruce@gnuradio:~/gnuradio-3.7.2.1/build> ctest -V -R
constellation_receiver
UpdateCTestConfiguration  from
:/home/bruce/gnuradio-3.7.2.1/build/DartConfiguration.tcl
UpdateCTestConfiguration  from
:/home/bruce/gnuradio-3.7.2.1/build/DartConfiguration.tcl
Test project /home/bruce/gnuradio-3.7.2.1/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 142
    Start 142: qa_constellation_receiver

142: Test command: /usr/bin/sh
"/home/bruce/gnuradio-3.7.2.1/build/gr-digital/python/digital/qa_constellation_receiver_test.sh"
142: Test timeout computed to be: 9.99988e+06
142: Using Volk machine: sse4_a_64
142: thread[thread-per-block[1]: <block constellation_receiver_cb
(477)>]:
boost::bad_any_cast: failed conversion using boost::any_cast

If I try to run the complete test set, it never finishes. I've left it
running for more than an hour..
Bruce



--
View this message in context:
http://gnuradio.4.n7.nabble.com/make-test-failure-...
Sent from the GnuRadio mailing list archive at Nabble.com.
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2014-01-06 18:50
(Received via mailing list)
On Sat, Jan 4, 2014 at 9:27 PM, ibmsorcerer <brucehoe@yahoo.com> wrote:
> Test project /home/bruce/gnuradio-3.7.2.1/build
> 142: Using Volk machine: sse4_a_64
> 142: thread[thread-per-block[1]: <block constellation_receiver_cb (477)>]:
> boost::bad_any_cast: failed conversion using boost::any_cast
>
> If I try to run the complete test set, it never finishes. I've left it
> running for more than an hour..
> Bruce


Bruce, what version of Boost are you using? Do any other tests throw
out that boost::bad_any_cast failure but complete anyways?

Tom
2bf444db9eb21e09279aa2b6557861de?d=identicon&s=25 ibmsorcerer (Guest)
on 2014-01-06 22:24
(Received via mailing list)
Tom,
I believe that I'm running the version that comes with SuSE 11 and
updated to SP3. v 1.36.0-12.3.1. I'm using it, because I thought that
the easy installation of many of the necessary libraries/tools might
make it convenient and easier to build gnu-radio.

All of the others worked fine, after I exclude the test for
qa_constellation_receiver.
    100% tests passed, 0 tests failed out of 175

After the test failure, I've not done anything further, because I didn't
think I could.

Bruce


________________________________
 From: Tom Rondeau-2 [via GnuRadio] <ml-node+s4n45610h79@n7.nabble.com>
To: ibmsorcerer <brucehoe@yahoo.com>
Sent: Monday, January 6, 2014 9:49 AM
Subject: Re: make test failure at qa_constellation_receiver



On Sat, Jan 4, 2014 at 9:27 PM, ibmsorcerer <[hidden email]> wrote:

________________________________


Bruce, what version of Boost are you using? Do any other tests throw
out that boost::bad_any_cast failure but complete anyways?

Tom

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




________________________________

If you reply to this email, your message will be added to the discussion
below:
http://gnuradio.4.n7.nabble.com/make-test-failure-...
To unsubscribe from make test failure at qa_constellation_receiver,
click here.
NAML

boost-versions.jpg (71K)
<http://gnuradio.4.n7.nabble.com/attachment/45611/0...
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2014-01-10 20:40
(Received via mailing list)
On Mon, Jan 6, 2014 at 4:23 PM, ibmsorcerer <brucehoe@yahoo.com> wrote:

> After the test failure, I've not done anything further, because I didn't
> think I could.
>
> Bruce
>

That seems strange that you're using Boost 1.36; that version is quite
old.
But I think that's correct. It looks like OpenSuse is using boost 1.53.

We build against Boost 1.35; that's the minimum version we support. On
the
other hand, it's probably been a while since anyone's tried to run
against
a version that old. I know most people who use distros with older
packages,
like CentOS/Redhat, tend to hand-install a version of Boost that's much
newer.

Having said that, we say we build and run against Boost 1.35, so until
we
produce a new version, we should still. I'll have to see if I can
install
and test against that and verify that that's the problem.

Tom
2bf444db9eb21e09279aa2b6557861de?d=identicon&s=25 ibmsorcerer (Guest)
on 2014-02-20 07:45
(Received via mailing list)
Tom,
 Any update on this issue?


________________________________
 From: Bruce Hoenig <brucehoe@yahoo.com>
To: Tom Rondeau-2 [via GnuRadio] <ml-node+s4n45610h79@n7.nabble.com>
Sent: Monday, January 6, 2014 1:22 PM
Subject: Re: make test failure at qa_constellation_receiver



Tom,
I believe that I'm running the version that comes with SuSE 11 and
updated to SP3. v 1.36.0-12.3.1. I'm using it, because I thought that
the easy installation of many of the necessary libraries/tools might
make it convenient and easier to build gnu-radio.

All of the others worked fine, after I exclude the test for
qa_constellation_receiver.
    100% tests passed, 0 tests failed out of 175

After the test failure, I've not done anything further, because I didn't
think I could.

Bruce


________________________________
 From: Tom Rondeau-2 [via GnuRadio] <ml-node+s4n45610h79@n7.nabble.com>
To: ibmsorcerer <brucehoe@yahoo.com>
Sent: Monday, January 6, 2014 9:49 AM
Subject: Re: make test failure at qa_constellation_receiver



On Sat, Jan 4, 2014 at 9:27 PM, ibmsorcerer <[hidden email]> wrote:

________________________________


Bruce, what version of Boost are you using? Do any other tests throw
out that boost::bad_any_cast failure but complete anyways?

Tom

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.