Hi Guys,
Constellation soft decoder crashes for constellation_bpsk() and
constellation_8psk(). I could not find the cause of this problem, the
back trace on my machine points to
gnuradio/gr-digital/lib/constellation.cc:286
for(int j = 0; j < k; j++) {
which does not make any sense. Any idea what could go wrong?
Miklos
Seems like a strange error for C++. I usually get for loop errors with C
where you can’t declare variables in the for loop. Perhaps try to
declare j
outside the for loop.
AM KC3BBL
Could you post the whole backtrace (as a github gist, pastebin etc)?
That would be very helpful, along with information such as:
Compiler (Gcc (version), VC++, clang …), Platform (Linux, win,
mac,…),
architecture (x86(64), ARMv9, IBM S7390,…) and GNU Radio source
version.
Thanks and happy hacking,
Marcus
Hi Marcus,
I do not think it is a compiler bug, but something uninitialized.
Constellation_qpsk and constellation_calcdist does not crash (I did
not verify if they work). However, if I generate the LUT for
constellation_qpsk, then it crashes.
Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Using latest master branch of gnuradio, hash 117058bac41c91, both
CMAKE_BUILD_TYPE=Debug and Release produces the same behavior
which python coreReading symbols from /usr/bin/python2.7…(no debugging symbols
found)…done.
warning: core file may not match specified executable file.
[New LWP 2249]
[New LWP 2251]
[New LWP 2240]
[New LWP 2248]
[New LWP 2247]
[New LWP 2239]
[New LWP 2250]
warning: Can’t read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library
“/lib/x86_64-linux-gnu/libthread_db.so.1”.
Core was generated by `python ./constellation_simulation.py’.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=…, npwr=)
at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
286 for(int j = 0; j < k; j++) {
i stack
#0 0x00007f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=…, npwr=)
at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
#1 0x00007f98dbbe0f7e in
gr::digital::constellation::soft_decision_maker (
this=0x48321c0, sample=…)
at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
#2 0x00007f98dbbe94dc in
gr::digital::constellation_soft_decoder_cf_impl::work (this=0x4fb11a0,
noutput_items=8190, input_items=…, output_items=…)
at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
#3 0x00007f98e1c5dd38 in gr::sync_interpolator::general_work (
this=0x4fb11c0, noutput_items=, ninput_items=…,
input_items=…, output_items=…)
at
/home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
You should be able to reproduce the problem quite easily, but if
needed I can provided a test program.
Best,
Miklos
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well, after having a debug build and then adding a lot of "volatile"s
into the code at the crashing function, it looks as if the
d_pre_diff_code of the constellation has size 0; and thus, you can’t
access the 0. (read: first) element. How this could happen with a QPSK
object is currently subject to my confusion. Stay tuned for more
confusing facts as the code unfolds :).
Greetings,
Marcus
On 16.12.2013 08:30, Miklos M. wrote:
gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
warning: Can’t read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled] Using host
libthread_db library “/lib/x86_64-linux-gnu/libthread_db.so.1”.
Core was generated by `python ./constellation_simulation.py’.
Program terminated with signal 11, Segmentation fault. #0
0x00007f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=…, npwr=) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
286 for(int j = 0; j < k; j++) {
i stack #0 0x00007f98dbbe01a7 in
gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
sample=…, npwr=) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
#1 0x00007f98dbbe0f7e in
gr::digital::constellation::soft_decision_maker (
this=0x48321c0, sample=…) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
#2 0x00007f98dbbe94dc in
gr::digital::constellation_soft_decoder_cf_impl::work
(this=0x4fb11a0, noutput_items=8190, input_items=…,
output_items=…) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
#3 0x00007f98e1c5dd38 in gr::sync_interpolator::general_work (
wrote:
Hi Guys,
Miklos
Discuss-gnuradio mailing list [email protected]
Discuss-gnuradio Info Page_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSrvNkAAoJEAFxB7BbsDrLTuIIAKGc2OjoUYgV3Lw8SuarcCjb
awWSZUC+jGxiOs5meaDOcfVsR8Viv9D0G98s6Ck0U6uHkJ1GPvzLLkRbxonPEhcB
syFs4Uz4nhqYddfuiNTyG4LhWXPWC3i/rm53lngIO50zBRelrGwxWIg4y5VyKwfV
JZfQ3duH+4JBe81VNuUw9Cb6/xhxHORD65AhnwOQBYU4w1mIrP1kNokfsFkXK/WN
e55jg+inffiRAg47Bz5wl0SsYGFrlNRNq+JnEmCMCR74c5xNE8T3ZO/NfDGxEwjl
fqXhY3ZpWqcoFOnizepUs8qvdzosveaFYKF+R474IkoBGZxUMn0Q5d+GxNAhxj4=
=G4mf
-----END PGP SIGNATURE-----
On 12/16/2013 08:16 AM, Miklos M. wrote:
Hi Marcus,
Ok, that makes sense. It does not crash with QPSK, but it does with
BPSK and 8PSK, and BPSK and 8PSK do not set the pre_diff_code. This
explains why there is crash in one case and not the other. Although
neither sets the apply_pre_diff_code, so even QPSK should not set
pre_diff_code.
I took a quick look in Coverity for issues in gr-digital. It flags a
bunch of uninitialized variables. I’ll try and take a look at these this
week.
There is an intermittent QA failure in some QA code and this might be an
explanation.
Philip
On Mon, Dec 16, 2013 at 8:16 AM, Miklos M.
[email protected] wrote:
(By the way, I do not understand the usefulness of pre_diff_code. Can
you just permute the constellation points and get the same effect?)Miklos
Miklos,
Can you try to attached patch? I had made the assumption that
pre_diff_code was always set in the constellation objects.
And yes, the pre_diff_code is essentially a LUT for the permutation.
Tom
Hi Marcus,
Ok, that makes sense. It does not crash with QPSK, but it does with
BPSK and 8PSK, and BPSK and 8PSK do not set the pre_diff_code. This
explains why there is crash in one case and not the other. Although
neither sets the apply_pre_diff_code, so even QPSK should not set
pre_diff_code.
I think the real problem is in constellation::calc_soft_dec. I does
not check whether d_apply_pre_diff_code is set or not.
(By the way, I do not understand the usefulness of pre_diff_code. Can
you just permute the constellation points and get the same effect?)
Miklos
Hi Marcus,
Anyway, I think Miklos is right: There is an error in calc_soft_dec in
using the pre_diff_code even in the case that it is not set or its
application disabled.Miklos, would you be as nice as to file a bug for that? You’re the one
who successfully diagnosed that.
Can you guys add me to the list of developers (user name: mmaroti)?
Then I can file the bug report.
In the mean time, I might be able to put together a pull request, just
fixing the calc_soft_dec code.
(You may, btw, simply think of
pre_diff_code simply as an index set of the constellation points)
I do not understand. It is just an extra permutation of the
constellation points. If this is so, then why do you not just permute
the constellation points, which makes everything faster. Do you have
any use case where simply permuting the constellation vector would not
achieve the same result?
I also worry about performance. Even for BPSK, QPSK and 8PSK the soft
decoding is not optimized, but could be much simpler than the general
algorithm. Same goes for QAM, but I have not looked those really
closely.
Miklos
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Phil, hi Miklos,
as far as I can tell, the default constructor of constellation doesn’t
initialize d_pre_diff_code, which is correct (well, kind of correct)
considering that it does not set any constellation points, either.
So I guess both members are initialized with their default
constructor, i.e. empty std::vectors or , respectively.
I don’t really know how to elegantly fix this. I don’t know if one
should remove the default constructor (and modify the depending
constellation_Xpsk constructors), or if that will break even more
things. Maybe the way to go would be having a method that sets the
constellation and automatically sets the pre_diff_code automatically
with the index range, just to prevent that error. This might however
be wasteful, for larger codes. Maybe one would just add a delegator
that either returns d_pre_diff_code[i] or just i, depending on the
existence of the predifferential codebook.
Anyway, I think Miklos is right: There is an error in calc_soft_dec in
using the pre_diff_code even in the case that it is not set or its
application disabled.
Miklos, would you be as nice as to file a bug for that? You’re the one
who successfully diagnosed that. (You may, btw, simply think of
pre_diff_code simply as an index set of the constellation points)
Greetings,
Marcus
On 16.12.2013 14:29, Philip B. wrote:
a bunch of uninitialized variables. I’ll try and take a look at
has size 0; and thus, you can’t access the 0. (read: first)
uninitialized. Constellation_qpsk and
Using latest master branch of gnuradio, hash
warning: Can’t read pathname for load map: Input/output
286 for(int j = 0; j < k; j++) {
i stack #0 0x00007f98dbbe01a7 in
gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=…, npwr=) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
#1 0x00007f98dbbe0f7e in
gr::digital::constellation::soft_decision_maker (
this=0x48321c0, sample=…) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
#2 0x00007f98dbbe94dc in
gr::digital::constellation_soft_decoder_cf_impl::work
(this=0x4fb11a0, noutput_items=8190, input_items=…,
output_items=…) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
#3 0x00007f98e1c5dd38 in gr::sync_interpolator::general_work (
this=0x4fb11c0, noutput_items=,
ninput_items=…, input_items=…, output_items=…) at
/home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
You should be able to reproduce the problem quite easily, but if
(x86(64), ARMv9, IBM S7390,…) and GNU Radio source
not find the cause of this problem, the back trace on
Discuss-gnuradio mailing list [email protected]
Discuss-gnuradio Info Page
_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSrwVRAAoJEAFxB7BbsDrLhd8H/0q7o3KX9iCShBn/X7VehxF2
LdR1peDL2VSqbGTmKnm6CltUs1yP7+bCAp+s6/TqTun7ticxDBSnh/0Drsc1jO2d
5E0UUKjjvuhdqKXfxbC/MGGSXlJ1Q1yGkkhmFvPS9ztQTT/Q3iLD8tFNshXdXlKc
FmPpyDWFDDD741AnqM4R5cXPnwUJkPV7aIvevYyrfYbjpSiK0t4yED0LVOZywnjs
aP2YB49qmWLpLYFAaIytcJF8cFkfumziPNQwpgndaZl8tuvwvUm7COHxXmBTdaqI
2IrB8gns+hR05uU9UAJdwaVI2gKGRB1hmP0MaHUxPd80ODfscTd5TAMxasBDWmE=
=HkF/
-----END PGP SIGNATURE-----
On Mon, Dec 16, 2013 at 1:08 PM, Miklos M.
[email protected] wrote:
Miklos
Miklos,
You must have overlooked my email. I sent and already applied a patch
for this. I’m going to go ahead and close this bug.
The scaling is done to make our slicing easier to perform. It was a
design decision by the original author. I don’t understand how this
prevents you from doing “interesting stuff” since it’s just a scaling
factor. Unless floating point accuracy is really that big of a deal to
what you want to do.
That having been said, we probably don’t actually need to impose this
so strictly. We can probably add another argument to the constellation
constructor to pass this value in, default it to 0, and if it’s 0, do
the autoscaling we currently do.
Tom
Hi Guys,
Ok, I have sent a pull request.
On a related note: I do not understand the scaling performed in the
constellation constructor. Why are the constellation points scaled to
have average 1.0 amplitude? It prevents me to do interesting stuff
with constellations. Why cannot I set the d_scalefactor manually later
(this is used in calc_soft_dec)?
Miklos
Hi Tom,
On Mon, Dec 16, 2013 at 7:27 PM, Tom R. [email protected] wrote:
Miklos
Miklos,
You must have overlooked my email. I sent and already applied a patch
for this. I’m going to go ahead and close this bug.
Sorry, I did not read then carefully.
The scaling is done to make our slicing easier to perform. It was a
design decision by the original author. I don’t understand how this
prevents you from doing “interesting stuff” since it’s just a scaling
factor. Unless floating point accuracy is really that big of a deal to
what you want to do.
You would have a multiplier block just because your constellation is
scaled (and you have to recompute the scaling factor manually just to
compensate).
That having been said, we probably don’t actually need to impose this
so strictly. We can probably add another argument to the constellation
constructor to pass this value in, default it to 0, and if it’s 0, do
the autoscaling we currently do.
That would be a nice to have.
Miklos
Thanks. Miklos
On Mon, Dec 16, 2013 at 5:18 PM, Miklos M.
[email protected]wrote:
Can you guys add me to the list of developers (user name: mmaroti)?
Then I can file the bug report.
In case this wasn’t the case, you now have access to the wiki.
MB
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs