Forum: GNU Radio Problem feeding garbage to GNU Radio

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Philip B. (Guest)
on 2008-10-10 23:00
(Received via mailing list)
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
Dan H. (Guest)
on 2008-10-10 23:11
(Received via mailing list)
-----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 :) ), 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-----
Eric B. (Guest)
on 2008-10-11 20:08
(Received via mailing list)
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
Philip B. (Guest)
on 2008-10-11 21:05
(Received via mailing list)
Attachment: top_block.py (0 Bytes)
On Sat, Oct 11, 2008 at 12:06 PM, Eric B. <removed_email_address@domain.invalid> 
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...

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
Johnathan C. (Guest)
on 2008-10-11 21:12
(Received via mailing list)
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.
Johnathan C. (Guest)
on 2008-10-11 21:18
(Received via mailing list)
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.)
Eric B. (Guest)
on 2008-10-12 07:15
(Received via mailing list)
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...
>
> 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-wri...

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

See above.

> Philip

Eric
Philip B. (Guest)
on 2008-10-14 05:48
(Received via mailing list)
On Sat, Oct 11, 2008 at 11:14 PM, Eric B. <removed_email_address@domain.invalid> 
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
This topic is locked and can not be replied to.