Hi Ale - Unfortunately the files & images don't really provide useful info on
the issue you're encountering. Much better would be to attach the output of the
"cmake" command, e.g., "cmake .. > cmake_out.txt 2>&1", including whatever
cmake arguments you issue. Please note the actual cmake
Thanks, Marcus:re-built with debug symbols. v3.7.11.1
Attached is the flowgraph causing the problem
- both the GRC and the resultant top_block.py
It uses an OOT module that talks to OpenHPSDR hardware
over Ethernet - should have one thread running to receive Ethernet frames.
from:
Hi,
(The question is not very specific to gr-ieee 802.11 :) )
I have made a pdu frame counter in gr-ieee 802.11. For that I have done
some modifications in parse_mac.cc (line 272, file attached). Its very
small change where I do
*d_total_packets += 1;*
after every successful wfi frame
Hi Tom!
Hm, no, I wouldn't be aware of any limitations, and even if such exist,
things shouldn't die with a std::bad_alloc!
Ok, so I'm wondering how we can move forward with this. Let us try
this:
* Can you share a proof of failure flow graph with us? That way,
everyone's definitely talking
Ah, I said:
>(gdb)break std::bad_alloc::what()⏎
>
> (it should NOT complain that this symbol isn't already loaded. If it
> does, we might need to install the libststc++ debug symbols; haven't
> used Ubuntu in a while, but probably `apt install libstdc++-dbg` or
> `-dbgsym`
I was wrong, at that
