Run to Completion with gr-ieee80211

I’ve derived a flow graph, playback_wifi_rx_cli.grc [1] from the wifi_rx
example given in gr-ieee80211 [2] which is a CLI version taking a
sc16-formatted sample file and outputs a .pcap file for wireshark. The
goal is to use this CLI program for batch data processing in my
research. Unfortunately, I am having an issue with “run to completion”.
The program executes, processes all the data, but never exits. I’ve
followed the debugging steps given in [3]. Output is below:

[Thread debugging using libthread_db enabled]
Using host libthread_db library
“/lib/x86_64-linux-gnu/libthread_db.so.1”.
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.003-0-ge10df19c

Using Volk machine: avx_64_mmx

( … launching lots of threads … )

^Z
Program received signal SIGTSTP, Stopped (user).
0x00007ffff78e8c33 in select () at …/sysdeps/unix/syscall-template.S:81
81 …/sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) info threads
Id Target Id Frame
23 Thread 0x7fff83fff700 (LWP 18714) “python”
[email protected]@GLIBC_2.3.2 ()
at …/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
22 Thread 0x7fffa4ff9700 (LWP 18713) “file_sink16”
[email protected]@GLIBC_2.3.2 ()
at
…/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
21 Thread 0x7fffa57fa700 (LWP 18712) “wireshark_conn1”
[email protected]@GLIBC_2.3.2 ()
at …/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

  • 1 Thread 0x7ffff7fd5740 (LWP 18689) “python” 0x00007ffff78e8c33 in
    select ()
    at …/sysdeps/unix/syscall-template.S:81

It appears the wireshark block is the cause of the hangup. Looking into
the source code [4], there is a provision for an EOF object
"is_eof_object()”. Which block sends this object? I enabled debugging
and the wireshark block never receives it. It seems like maybe the file
source should send it at the EOF of the file. If y’all could explain how
the object is sent and perhaps point me in the right direction for
additional debugging that would be most helpful. Thanks!

PWG

[1]
https://github.com/garverp/gr-ieee802-11/blob/offline_processing/examples/playback_wifi_rx_cli.grc
https://github.com/garverp/gr-ieee802-11/blob/offline_processing/examples/playback_wifi_rx_cli.grc
[2] https://github.com/bastibl/gr-ieee802-11
https://github.com/bastibl/gr-ieee802-11
[3]
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-04/msg00002.html
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-04/msg00002.html
[4]
https://github.com/bastibl/gr-foo/blob/master/lib/wireshark_connector_impl.cc
https://github.com/bastibl/gr-foo/blob/master/lib/wireshark_connector_impl.cc

Hi,

grrr, this topic…

On 06/03/2015 06:04 PM, Paul G. wrote:

It appears the wireshark block is the cause of the hangup. Looking into
the source code [4], there is a provision for an EOF object
"is_eof_object(). Which block sends this object?

This code is a bit older when there was no system_handler. For my
simulations I used a message source that generated n messages followed
by an EOF object that was used to shutdown the flow graph.

Now there is this system_handler stuff. Each block has a message port
(hidden in GRC) that can be used to stop the block. So the EOF stuff
should be obsolete, however I left it there since I had some problems
with the system handler.

I enabled debugging
and the wireshark block never receives it. It seems like maybe the file
source should send it at the EOF of the file. If yall could explain how
the object is sent and perhaps point me in the right direction for
additional debugging that would be most helpful. Thanks!

I also debugged a bit: The decode_mac block stops correctly and also
sends a “done” message to the system handler of the wireshark_connector.
The handler is process, but that doesn’t stop the block from calling its
work function again and again. Actually the scheduler should realize
that the block is done and not call its work function, but notify
downstream blocks (in that case the file sink).
I substituted the wireshark_connector with a PDU to Tagged Stream block
and it’s the same. So maybe it’s not my fault.

I personally use this patch

https://github.com/bastibl/gnuradio/commit/5930587f388dfebea40cab6e5e919b41e455ae0d

but it’s very old an I forgot why what it does.

You can also try to add “d_detail->set_done(true);” here
https://github.com/gnuradio/gnuradio/blob/next/gnuradio-runtime/lib/block.cc#L710

this also worked for me (might break other stuff though :-))

Best,
Bastian

I tried to create a minimal example of the problem:

http://www.ccs-labs.org/~bloessl/not_stopping.grc

Hi Bastian,

Thanks for the response and the simplified example. Maybe someone who
understands the scheduler a bit better can chime in and let us know the
scope of the issue here. Im happy to dig into the details but it would
be good to know if this is a fundamental issue with the scheduler or a
simple fix. I thought based on [1] this was an issue with python
message-only blocks, but everything here should be c++. Like you, Ive
previously implemented some work-arounds such as having the file pointer
location in file source accessible. But it seems this issue is not
application specific and thus it sure would be nice to have the fix in
the baseline vs. running custom file source blocks, forks of GR, etc.

[1]
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-04/msg00093.html
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-04/msg00093.html

PWG

I ran gdb on your provided example and the exact same thing happens as
in wireshark_connector. So, Ive rolled this up into a bug report since
we can replicate it with baseline code (pdu_to_tagged_stream). Im yet to
be convinced this is application specific as it seems to be an issue
with gnuradio-runtime.

http://gnuradio.org/redmine/issues/797
http://gnuradio.org/redmine/issues/797

PWG

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs