Hi, grrr, this topic...
On 06/03/2015 06:04 PM, Paul Garver 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 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!
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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
