Problem feeding garbage to GNU Radio

I’m working on a flow graph that reads samples from a file and feeds
them to the wfm demod block. I managed to get this working, but along
the way I ran across a problem …

My data file is 16bit complex shorts in big-endian format. It looks
like the file source block reads data from the file and sends it to
the fm demod which is expecting a complex float data. I attempted a
quick test by using the original data file (wrong format) which caused
the flow graph to crash with a seg fault. After converting the data to
a complex float representation the flowgraph works.

Do people view this as a problem? It seems like the file source block
should attempt some form of sanity checking on incoming data. If you
aren’t expecting a problem, I could see this being hard for people new
to GNU Radio to debug.

Philip

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Oct 10, 2008, at 11:59 AM, Philip B. wrote:

My data file is 16bit complex shorts in big-endian format. It looks
like the file source block reads data from the file and sends it to
the fm demod which is expecting a complex float data. I attempted a
quick test by using the original data file (wrong format) which caused
the flow graph to crash with a seg fault. After converting the data to
a complex float representation the flowgraph works.

IIRC, (from doing the same thing :slight_smile: ), it’s really easy to get
file_source to read invalid float/double values and get a bunch of
NaNs in the input.

Is it worth the overhead of checking every single read for this?
Probably not. But maybe we should do something about it… add an
option for instance. Or more graceful handling of NaNs in some of the
processing blocks.

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjvqCYACgkQy9GYuuMoUJ6uugCaAt42i6ZIVp3dqcZUAU96WGiz
pkUAn0hpOw1O7KtGk1dCA2cUFSbTITK5
=jL2i
-----END PGP SIGNATURE-----

On Fri, Oct 10, 2008 at 02:59:33PM -0400, Philip B. wrote:

Do people view this as a problem? It seems like the file source block
should attempt some form of sanity checking on incoming data. If you
aren’t expecting a problem, I could see this being hard for people new
to GNU Radio to debug.

Philip

It shouldn’t segfault regardless of the input.

Can you send or post a link to the flow graph and the test data that
reproduces the problem?

A gdb stack trace would let us know where it’s blowing up.
From there the bug should be easy to find and fix.

Eric

On Sat, Oct 11, 2008 at 12:06 PM, Eric B. [email protected] wrote:

a complex float representation the flowgraph works.
Can you send or post a link to the flow graph and the test data that
reproduces the problem?

A gdb stack trace would let us know where it’s blowing up.
From there the bug should be easy to find and fix.

I’ve attached the flow graph.

The data file is here:

http://ossie.wireless.vt.edu/~balister/capture/npr_iq_sample.dat

Right now I’m working through figuring out how many python modules are
needed to run the flow graph, if I have a chance I’ll try and get a
stack trace. I’m assuming you gsb python and run the flow graph? Arg,
how do I get the python interpreter to load and run top_block.py …

Philip

On Sat, 2008-10-11 at 13:04 -0400, Philip B. wrote:

if name == ‘main’:
print(“Create top block”)
tb = top_block()
print(“start top block”)
tb.start()
print(“started top block”)
raw_input('Press Enter to quit: ')
tb.stop()

Just FYI–if you start() a flowgraph instead of using run(), you are
responsible both for invoking stop() at the right point (which you are),
as well as invoking wait(), which allows all the flowgraph threads to
exit cleanly before Python continues (in this case, exits out the bottom
of the script.)

On Sat, 2008-10-11 at 13:04 -0400, Philip B. wrote:

Right now I’m working through figuring out how many python modules are
needed to run the flow graph, if I have a chance I’ll try and get a
stack trace. I’m assuming you gsb python and run the flow graph? Arg,
how do I get the python interpreter to load and run top_block.py …

Add a few lines at the very beginning of your script:

import os
print “pid =”, os.getpid()
raw_input(“Press enter to continue”)

Run your script as you would normally; it will pause here.

In another window, run ‘gdb -p XXXX’ where XXXX is the pid printed by
your Python script. When it gets to its prompt, enter ‘cont’.

Now you can press Enter in your Python script and the whole thing will
be running under the control of gdb. When you get the segfault, you
won’t see it in the terminal with Python running; it will just appear to
freeze. But if you go back to the terminal running gdb, you will see it
has taken over and will have printed some information about the type and
location of the segfault.

You can use the ‘bt’ command to print the current execution stack in the
offending thread.

On Sat, Oct 11, 2008 at 11:14 PM, Eric B. [email protected] wrote:

quick test by using the original data file (wrong format) which caused
It shouldn’t segfault regardless of the input.

how do I get the python interpreter to load and run top_block.py …
Should this move to the gnuradio.org wiki so people searching for gdb
can find this information?

Philip

On Sat, Oct 11, 2008 at 01:04:55PM -0400, Philip B. wrote:

the flow graph to crash with a seg fault. After converting the data to

http://ossie.wireless.vt.edu/~balister/capture/npr_iq_sample.dat

Right now I’m working through figuring out how many python modules are
needed to run the flow graph, if I have a chance I’ll try and get a
stack trace. I’m assuming you gsb python and run the flow graph? Arg,

You only need to make a two line change in your code to hookup gdb to
the running python image. See:
http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html#debugging

how do I get the python interpreter to load and run top_block.py …

See above.

Philip

Eric