# Run to Completion with gr-ieee80211 **URL:** \ **Category:** GNU Radio\ **Created:** [June 3, 2015, 6:05pm UTC](https://www.ruby-forum.com/t/run-to-completion-with-gr-ieee80211/242195 "2015-06-03T18:05:21Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [June 3, 2015, 6:05pm UTC](https://www.ruby-forum.com/t/run-to-completion-with-gr-ieee80211/242195/1 "2015-06-03T18:05:21Z")
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” pthread\_cond\_wait@@GLIBC\_2.3.2 () at …/nptl/sysdeps/unix/sysv/linux/x86\_64/pthread\_cond\_wait.S:185 22 Thread 0x7fffa4ff9700 (LWP 18713) “file\_sink16” pthread\_cond\_timedwait@@GLIBC\_2.3.2 () at …/nptl/sysdeps/unix/sysv/linux/x86\_64/pthread\_cond\_timedwait.S:238 21 Thread 0x7fffa57fa700 (LWP 18712) “wireshark\_conn1” pthread\_cond\_wait@@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] [GitHub - bastibl/gr-ieee802-11: IEEE 802.11 a/g/p Transceiver](https://github.com/bastibl/gr-ieee802-11) [https://github.com/bastibl/gr-ieee802-11](https://github.com/bastibl/gr-ieee802-11) [3] [Re: [Discuss-gnuradio] "Run to completion" not working with message pass](https://lists.gnu.org/archive/html/discuss-gnuradio/2015-04/msg00002.html) [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) [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) ---
**Author:** ![uddun](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/f19dbf/32.png) [@uddun](https://www.ruby-forum.com/u/uddun)\ **Post date:** [June 4, 2015, 12:48pm UTC](https://www.ruby-forum.com/t/run-to-completion-with-gr-ieee80211/242195/2 "2015-06-04T12:48:10Z")
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 > > > Conflicts: > volk 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](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 ---
**Author:** ![uddun](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/f19dbf/32.png) [@uddun](https://www.ruby-forum.com/u/uddun)\ **Post date:** [June 4, 2015, 1:48pm UTC](https://www.ruby-forum.com/t/run-to-completion-with-gr-ieee80211/242195/3 "2015-06-04T13:48:55Z")
I tried to create a minimal example of the problem: > **[Home](https://www.bastibl.net/)** > > I'm Bastian Bloessl, a Postdoctoral Researcher at SEEMOO, TU Darmstadt. Checkout my blog, projects, publications, and resume; or connect on Github, Twitter, YouTube, or Facebook. ---
**Author:** ![uddun](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/f19dbf/32.png) [@uddun](https://www.ruby-forum.com/u/uddun)\ **Post date:** [June 4, 2015, 3:22pm UTC](https://www.ruby-forum.com/t/run-to-completion-with-gr-ieee80211/242195/4 "2015-06-04T15:22:23Z")
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) [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 ---
**Author:** ![uddun](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/f19dbf/32.png) [@uddun](https://www.ruby-forum.com/u/uddun)\ **Post date:** [June 10, 2015, 10:34pm UTC](https://www.ruby-forum.com/t/run-to-completion-with-gr-ieee80211/242195/5 "2015-06-10T22:34:31Z")
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) [http://gnuradio.org/redmine/issues/797](http://gnuradio.org/redmine/issues/797) PWG