Re: [Discuss-gnuradio] Video Streaming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Syed, test 2 should be completely transparent and thus you shouldn't lose quality. The input bitrate of the video is below 1Mb/s, so for a pure loopback test I can't imagine this going wrong. Are you sure that the sending VLC does *not* decode the video into something with a much higher bitrate. Also make sure you don't use throttle in between. Greetings, Marcus On 20.02.2014 11:32, Syed Aqeel Raza wrote: Hi I am trying to stream a video over a wireless network using UDP protocol. For that, I started tests in the following sequence: Test 1: VLC VLC Test 2: VLC Gnuradio (using udp source and udp sink blocks only) VLC Test 3: VLC Gnuradio (with a complete communication model (e.g. mod/demod)) VLC Test 4: VLC Gnuradio USRPs (multiple) VLC Test 1 completed successfully and the streamed video quality is perfect at the receiver end. Whereas, in test 2, test 3 and test 4 I've successfully got the streamed video at the receiver end but the quality is not good (it's even more degraded when shift to the higher test levels). During the testing a warning message appeared on gnuradio console i.e. Too much data; packet loss. I tried to resolve this issue by adjusting the factors like payload size and sampling rate but nothing works. The flowcharts and the video are attached here for reference. Furthermore, can anyone give me a hint that how can I check the parameters like throughput, packet delay and SNR. Kindly assist me and point out the mistake I've made, waiting for earliest reply. Thanks. Regards, Syed Aqeel Raza ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTBxjSAAoJEAFxB7BbsDrLzxcH/ip3m6F2ls0itx95IlN2qov0 f3etC7XX0XgF91uO9XwpLSdjsIjGaXz8G7Yc7zKCkrcBL9xVuYl/xpqHKwxy2gWL /FoROdlioZ7Nr/xWkuMTsRAJQgx/VIVWLSoSutdT4Bc7fc4z6lcosPDQ/ShUziw9 IZnfPfX2Wumh1QkOKkcIYxTjyIL1tqi6X2T3LrfHC3FBc2g3JL90xPFlc4hXfMHM 0zwkXNiSAVZxzRgbW5mHolygU80AvrP529B2mHD9hoiJfDTGLDvyxmsrU2E2Pc2Y GCnIJ5bHQBENcemYeGceKtRsd9MO7TV9RyTOR4q2ghhIn1z2W+WFMvY4JwRG800= =gDsk -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR 3.7.2.1 on OSX 10.8.5
On Feb 20, 2014, at 10:58 PM, Bruce bruce...@yahoo.com wrote: Where did you find that particular install? Hi Bruce - Ed is talking about using MacPorts to install GNU Radio; see also the various wiki pages related to these topics: http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR https://trac.macports.org/wiki/InstallingMacPorts If you need more assistance, email me off-list. Hope this helps! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR 3.7.2.1 on OSX 10.8.5
Hi Ed - Thanks for the kind words! All of the warnings you show are normal for OSX 10.8 or 10.9 and GNU Radio release in MacPorts. If you move to gnuradio-devel, you'll be able to get rid of the failed to XInitThreads() warning; if you move to 10.9, you'll get even more warnings if/when you run anything that uses WX. All of the warnings are normal and nothing to be concerned about. - MLD On Feb 20, 2014, at 6:37 PM, Ed Criscuolo edward.l.criscu...@nasa.gov wrote: I just upgraded my ports-installed version of GR 3.6.3 to GR 3.7.2.1 with a simple port upgrade gnuradio. The install went smoothly without errors and installed a working copy of 3.7.2.1 with only a few operational issues. Hats off to Michael Dickens for his superb job of supporting GnuRadio on OSX!! :) Michael, I got the following when starting gnuradio-companion: === ** (process:51809): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** (process:51809): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' ** (process:51809): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags' Warning: Block key blocks_ctrlport_monitor_performance not found when loading category tree. Warning: Block key blocks_ctrlport_monitor_performance not found when loading category tree. Mac OS; Clang version 4.1 ((tags/Apple/clang-421.11.66)); Boost_105500; UHD_003.007.000-0-unknown Welcome to GNU Radio Companion 3.7.2.1 === Also, when I run a flowgraph, I see this in the output: === Executing: /Users/edwardc/Work/gnu_radio/DAS_Test_01.py Warning: failed to XInitThreads() Using Volk machine: sse4_1_64_orc === Are either of these significant? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation fault in qa_constellation_receiver_test
On Fri, Feb 21, 2014 at 2:39 AM, West, Nathan n...@ostatemail.okstate.edu wrote: On Thu, Feb 20, 2014 at 11:25 PM, Kelly Boswell krbosw...@gmail.com wrote: After the make test failed for this module, I decided to poke around to see if there is an easy fix. I made a script that simply executes the test over and over until it seg faults and exits after the core file is created. x@:~/src/gnuradio/build/gr-digital/python/digital$ ./runtests.sh Using Volk machine: avx_64_mmx Segmentation fault (core dumped) x@:~/src/gnuradio/build/gr-digital/python/digital$ gdb /usr/bin/python2.7 core (gdb) bt (gdb) bt #0 0x7fe8f627fb17 in volk_32fc_32f_dot_prod_32fc_a_avx () from /home/kelly/src/gnuradio/build/volk/lib/libvolk.so.0.0.0 #1 0x7fe8f52dd25f in gr::filter::kernel::fir_filter_ccf::filter(std::complexfloat const*) () from /home/kelly/src/gnuradio/build/gr-filter/lib/libgnuradio-filter-3.8git.so.0.0.0 #2 0x7fe8f143c45b in gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /home/kelly/src/gnuradio/build/gr-digital/lib/libgnuradio-digital-3.8git.so.0.0.0 #3 0x7fe8f653809e in gr::block_executor::run_one_iteration() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #4 0x7fe8f6573622 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptrgr::block, int) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #5 0x7fe8f6565ea1 in boost::detail::function::void_function_obj_invoker0gr::thread::thread_body_wrappergr::tpb_container, void::invoke(boost::detail::function::function_buffer) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 ---Type return to continue, or q return to quit--- #6 0x7fe8f6526610 in boost::detail::thread_databoost::function0void ::run() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #7 0x7fe8f9adc94a in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 #8 0x7fe8fc8a3f6e in start_thread (arg=0x7fe8e2ffd700) at pthread_create.c:311 #9 0x7fe8fc5ce9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Of course, I had to recompile it with debugging info to glean anything useful from the stack trace. So, I did that and I traced the bug to this line: c0Val = _mm256_mul_ps(a0Val, b0Val); I can't dump the values in a0Val or b0Val, though, because they're intermediate values that are optimized away by the optimized kernel code. I tried stepping through the assembler instructions but I'm not familiar with the various sse and avx extensions. Heck, I'm not even familiar with the x86_64 instruction set. So I have a huge learning curve ahead of me, there. Is it possible to just dump the values in these __m256 data types to a file so I can debug it that way? If that's not easy to do, then I'm willing to learn what I have to about the instruction set so I can debug this thing. But I would sure appreciate some help if anyone has some advice to offer. Software version: I rebased to the latest version of the next branch last night before I went to bed at around 1:30 am CDT. Operating System: kelly@octs2:~/src/gnuradio/volk/kernels/volk$ uname -a Linux octs2 3.11.0-17-generic #31-Ubuntu SMP Mon Feb 3 21:52:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux It's Ubuntu 13.10 Hardware: ASUS X750J Intel Quad Core i7 4700HQ 2.4GHz cpuinfo: processor: 7 vendor_id: GenuineIntel cpu family: 6 model: 60 model name: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz stepping: 3 microcode: 0x8 cpu MHz: 2401.000 cache size: 6144 KB physical id: 0 siblings: 8 core id: 3 cpu cores: 4 apicid: 7 initial apicid: 7 fpu: yes fpu_exception: yes cpuid level: 13 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid bogomips: 4789.27 clflush size: 64 cache_alignment: 64 address sizes: 39 bits physical, 48 bits virtual power management: Hi Kelly, First, this is great debugging, thanks for getting so much info and trying to go for a fix on your own. On to the good stuff. I was able to reproduce
[Discuss-gnuradio] Piped Video Streaming Crash
Hello all
Sorry if this is a duplicate, haven't found a thread with me specific
config (no UDP).
System:
ubuntu 12.10
N2100
SBX
GNU Radio 3.7.2.1
UHD 003.006.002-1
I have been trying to set up a video link (loop back cable) using named
pipes but am stuck with a crash.
It works until I introduce the USRP into the loop. Though it is the same
set up I use to transmit I text file without trouble.
What I have done:
VLC - Named Pipe - VLC
(fail) - found reference to VLC bugs in forums so gave up on that
VLC - Named Pipe - Mplayer
(works)
VLC - Named Pipe 1 - File Source GRC - File Sink GRC - Named Pipe 2 -
Mplayer
(works)
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - OFDM DEMOD - File Sink
GRC - Named Pipe 2 - Mplayer
(works)
Now with hardware:
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP -Source -
OFDM DEMOD - File Sink GRC - Named Pipe 2 - Mplayer
(FAILS!!). Reports: Segfault (core dumped). GRC file is running, VLC is
streaming. Fail occurs as soon as I open Named Pipe 2 with Mplayer
However, this is the identical GRC - USRP setup I use to repeatedly
transmit a text file successfully.
I have no reason to believe the UHDlib is failing, the segfault I think is
a python crash?
The parameters I am using:
VLC:
cvlc v4l2:///dev/video0 :v4l2-width=160 :v4l2-height=120
:v4l2-aspect-ratio=4/3 --noaudio
--sout=#transcode{vcodec=h264,vb=1024}:file{dst=./txPIPE.ts} :sout-keep
USRP:
sample rate 12.5M
GRC: - not sure of the impact of these settings
These are the ones I am not so sure of:
File source, repeat yes or no?
File Sink, unbuffered on or off? append file on or off?
I am guessing my problem is related to sample rate, buffer sizes, frame
rate etc. I have tried a few permutations without luck though, but not
everything.
I have not set camera fps -
*v4l2-fps float*I have hoped the data flow back pressure would be dealt
with by perhaps VLC with default setting (zero)? Or I'd just miss frames on
reception?
Just looking for some suggestions here I as I have put a good bit of time
into this now without luck
regards
Alexander Buckley
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Piped Video Streaming Crash
Hi Alexander,
interesting approach!
Just a few quick questions to understand better:
Now with hardware:
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP -Source -
OFDM DEMOD - File Sink GRC - Named Pipe 2 - Mplayer
(FAILS!!). Reports: Segfault (core dumped). GRC file is running, VLC is
streaming. Fail occurs as soon as I open Named Pipe 2 with Mplayer
What is segfaulting? Mplayer or your Flowgraph?
If it's Mplayer I don't know, but it sounds like a solid Mplayer bug...
Also: Be aware that a named pipe might still have unread information from runs
before; I guess the safest way would be rm'ing and mkfifo'ing right before
every start.
GRC: - not sure of the impact of these settings
These are the ones I am not so sure of:
File source, repeat yes or no?
don't repeat. Wouldn't work anyway. a byte that came out of a named pipe is
gone forever :)
File Sink, unbuffered on or off? append file on or off?
buffering shouldn't change much, but since your fifo is basically a buffer,
just use unbuffered.
Appending on/off is meaningless for named pipe file descriptors. use the off
variant - it's how fifo's were meant to be used.
Do things work out if you replace Named Pipe 2 with an actual file and try to
play back that afterwards?
Greetings
Marcus
On 02/21/2014 03:41 PM, Alexander Buckley wrote:
Hello all
Sorry if this is a duplicate, haven't found a thread with me specific config
(no UDP).
System:
ubuntu 12.10
N2100
SBX
GNU Radio 3.7.2.1
UHD 003.006.002-1
I have been trying to set up a video link (loop back cable) using named pipes
but am stuck with a crash.
It works until I introduce the USRP into the loop. Though it is the same set up
I use to transmit I text file without trouble.
What I have done:
VLC - Named Pipe - VLC
(fail) - found reference to VLC bugs in forums so gave up on that
VLC - Named Pipe - Mplayer
(works)
VLC - Named Pipe 1 - File Source GRC - File Sink GRC - Named Pipe 2 - Mplayer
(works)
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - OFDM DEMOD - File Sink GRC -
Named Pipe 2 - Mplayer
(works)
Now with hardware:
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP -Source -
OFDM DEMOD - File Sink GRC - Named Pipe 2 - Mplayer
(FAILS!!). Reports: Segfault (core dumped). GRC file is running, VLC is
streaming. Fail occurs as soon as I open Named Pipe 2 with Mplayer
However, this is the identical GRC - USRP setup I use to repeatedly transmit a
text file successfully.
I have no reason to believe the UHDlib is failing, the segfault I think is a
python crash?
The parameters I am using:
VLC:
cvlc v4l2:///dev/video0 :v4l2-width=160 :v4l2-height=120 :v4l2-aspect-ratio=4/3 --noaudio
--sout=#transcode{vcodec=h264,vb=1024}:file{dst=./txPIPE.ts} :sout-keep
USRP:
sample rate 12.5M
GRC: - not sure of the impact of these settings
These are the ones I am not so sure of:
File source, repeat yes or no?
File Sink, unbuffered on or off? append file on or off?
I am guessing my problem is related to sample rate, buffer sizes, frame rate
etc. I have tried a few permutations without luck though, but not everything.
I have not set camera fps - *v4l2-fps float
*I have hoped the data flow back pressure would be dealt with by perhaps VLC
with default setting (zero)? Or I'd just miss frames on reception?
Just looking for some suggestions here I as I have put a good bit of time into
this now without luck
regards
Alexander Buckley
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issue while installing GR 3.7
Thanks Marcus, Actually the boost version I have is 1.54.0. Is this ok ? -- View this message in context: http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46451.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] on the fly set_output_multiple()
On 02/21/2014 12:38 AM, Activecat wrote: Problem: Says, the instantaneous interpolation_factor is 3. As inherited from gr::block, the scheduler may call the general_work() with noutput_items=2 (any number is possible). When this happen, there is nothing to be done except to consume_each(0) and return 0 in the general_work(). You could tweak forecast() to require more input. But then the scheduler will repeat calling general_work() many times with noutput_items=2. This is fatal. Solution: On the fly, set_min_noutput_items(3) Then the scheduler will not call general_work() with noutput_items equals a value less than 3. This solves the problems ! Question: Does this function work on the fly?set_min_noutput_items() It should, that's what it was made for. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Include guard bug (was: Re: Issue while installing GR 3.7)
Should be :) Just as side info: http://www.boost.org/doc/libs/1_54_0/doc/html/boost/random/mt19937.html Sorry, totally running low on clues here... This is twice as strange since boost::random is missing mt19937; if it was std:: I'd guess on a non-C++11 standard library, but like it is... If cleaning and rebuilding doesn't help, make sure that libstdc++-devel is correctly installed Basically, it should be right here: http://www.boost.org/doc/libs/1_54_0/boost/random/mersenne_twister.hpp and is included. AAAND bam. Found the bug. header include protection by #ifdef at the very beginning of the file. you might pull my bugfix from https://github.com/marcusmueller/gnuradio.git; git pull https://github.com/marcusmueller/gnuradio.git master_fix_message_strobe_random_ifndef Greetings, Marcus On 02/21/2014 04:00 PM, Ruecan wrote: Thanks Marcus, Actually the boost version I have is 1.54.0. Is this ok ? -- View this message in context: http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46451.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in gr::digital::mpsk_receiver_cc
On 02/21/2014 04:37 AM, Ed Criscuolo wrote: I checked the code, and indeed, there is no method by any name for setting the loop_bandwidth attribute. Ed, thanks -- could you please go the extra mile and post an issue on the tracker? M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include guard bug
Ruecan: I got carried away. This is indeed a bugfix for the header file not being processed in some cases, but since the error appeared although actually processing the fixed header file, I've run out of ideas, still. On 02/21/2014 04:37 PM, Marcus Müller wrote: Should be :) Just as side info: http://www.boost.org/doc/libs/1_54_0/doc/html/boost/random/mt19937.html Sorry, totally running low on clues here... This is twice as strange since boost::random is missing mt19937; if it was std:: I'd guess on a non-C++11 standard library, but like it is... If cleaning and rebuilding doesn't help, make sure that libstdc++-devel is correctly installed Basically, it should be right here: http://www.boost.org/doc/libs/1_54_0/boost/random/mersenne_twister.hpp and is included. AAAND bam. Found the bug. header include protection by #ifdef at the very beginning of the file. you might pull my bugfix from https://github.com/marcusmueller/gnuradio.git; git pull https://github.com/marcusmueller/gnuradio.git master_fix_message_strobe_random_ifndef Greetings, Marcus On 02/21/2014 04:00 PM, Ruecan wrote: Thanks Marcus, Actually the boost version I have is 1.54.0. Is this ok ? -- View this message in context:http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46451.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Video Streaming
On 02/20/2014 11:32 AM, Syed Aqeel Raza wrote: Kindly assist me and point out the mistake I've made, waiting for earliest reply. Thanks. Syed, this not a reasonable thing to ask for here. You have built an entire transceiver chain, and all you tell is that it's not working. Unless someone is extremely bored, no-one will help you with a request like this. No, I assume you actually want help, and are not posting this question to annoy anyone. Here's some advice: - Read this: http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors - Narrow down the problem. Convince us that you've tried many things to get it right. Without even looking at your flow graph, I assume there's several things that aren't working, since so much can go wrong in digital comms. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include guard bug
I just pulled the changes then did make but get the same error. I am not so familiar with git. After pulling your bugfix, do I need to make clean, remove the CMakeCache then do cmake again then make or am I missing some part of the process. -- View this message in context: http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46457.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include guard bug
Yeah, start completely clean. Very Respectfully, Dan CaJacob On Fri, Feb 21, 2014 at 11:17 AM, Ruecan naceuram...@gmail.com wrote: I just pulled the changes then did make but get the same error. I am not so familiar with git. After pulling your bugfix, do I need to make clean, remove the CMakeCache then do cmake again then make or am I missing some part of the process. -- View this message in context: http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46457.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation fault in qa_constellation_receiver_test
Thank you, Tom. I'll try that after I'm off of work tonight. And thank you for the great ideas, Nathan. On Fri, Feb 21, 2014 at 2:39 AM, West, Nathan n...@ostatemail.okstate.edu wrote: On Thu, Feb 20, 2014 at 11:25 PM, Kelly Boswell krbosw...@gmail.com wrote: After the make test failed for this module, I decided to poke around to see if there is an easy fix. I made a script that simply executes the test over and over until it seg faults and exits after the core file is created. x@:~/src/gnuradio/build/gr-digital/python/digital$ ./runtests.sh Using Volk machine: avx_64_mmx Segmentation fault (core dumped) x@:~/src/gnuradio/build/gr-digital/python/digital$ gdb /usr/bin/python2.7 core (gdb) bt (gdb) bt #0 0x7fe8f627fb17 in volk_32fc_32f_dot_prod_32fc_a_avx () from /home/kelly/src/gnuradio/build/volk/lib/libvolk.so.0.0.0 #1 0x7fe8f52dd25f in gr::filter::kernel::fir_filter_ccf::filter(std::complexfloat const*) () from /home/kelly/src/gnuradio/build/gr-filter/lib/libgnuradio-filter-3.8git.so.0.0.0 #2 0x7fe8f143c45b in gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /home/kelly/src/gnuradio/build/gr-digital/lib/libgnuradio-digital-3.8git.so.0.0.0 #3 0x7fe8f653809e in gr::block_executor::run_one_iteration() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #4 0x7fe8f6573622 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptrgr::block, int) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #5 0x7fe8f6565ea1 in boost::detail::function::void_function_obj_invoker0gr::thread::thread_body_wrappergr::tpb_container, void::invoke(boost::detail::function::function_buffer) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 ---Type return to continue, or q return to quit--- #6 0x7fe8f6526610 in boost::detail::thread_databoost::function0void ::run() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #7 0x7fe8f9adc94a in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 #8 0x7fe8fc8a3f6e in start_thread (arg=0x7fe8e2ffd700) at pthread_create.c:311 #9 0x7fe8fc5ce9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Of course, I had to recompile it with debugging info to glean anything useful from the stack trace. So, I did that and I traced the bug to this line: c0Val = _mm256_mul_ps(a0Val, b0Val); I can't dump the values in a0Val or b0Val, though, because they're intermediate values that are optimized away by the optimized kernel code. I tried stepping through the assembler instructions but I'm not familiar with the various sse and avx extensions. Heck, I'm not even familiar with the x86_64 instruction set. So I have a huge learning curve ahead of me, there. Is it possible to just dump the values in these __m256 data types to a file so I can debug it that way? If that's not easy to do, then I'm willing to learn what I have to about the instruction set so I can debug this thing. But I would sure appreciate some help if anyone has some advice to offer. Software version: I rebased to the latest version of the next branch last night before I went to bed at around 1:30 am CDT. Operating System: kelly@octs2:~/src/gnuradio/volk/kernels/volk$ uname -a Linux octs2 3.11.0-17-generic #31-Ubuntu SMP Mon Feb 3 21:52:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux It's Ubuntu 13.10 Hardware: ASUS X750J Intel Quad Core i7 4700HQ 2.4GHz cpuinfo: processor: 7 vendor_id: GenuineIntel cpu family: 6 model: 60 model name: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz stepping: 3 microcode: 0x8 cpu MHz: 2401.000 cache size: 6144 KB physical id: 0 siblings: 8 core id: 3 cpu cores: 4 apicid: 7 initial apicid: 7 fpu: yes fpu_exception: yes cpuid level: 13 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid bogomips: 4789.27 clflush size: 64 cache_alignment: 64 address sizes: 39 bits physical, 48 bits virtual power management: Hi Kelly, First, this is great debugging, thanks for getting
Re: [Discuss-gnuradio] Include guard bug
good find, this was probably my fault - sorry We should consider changing headers to use #pragma once which is simpler and less error prone do people still use gcc older than 3.4 ? I think this is pretty widely supported now not sure if that would cause swig issues as well - -Tim On 02/21/2014 10:51 AM, Marcus Müller wrote: Ruecan: I got carried away. This is indeed a bugfix for the header file not being processed in some cases, but since the error appeared although actually processing the fixed header file, I've run out of ideas, still. On 02/21/2014 04:37 PM, Marcus Müller wrote: Should be :) Just as side info: http://www.boost.org/doc/libs/1_54_0/doc/html/boost/random/mt19937.html Sorry, totally running low on clues here... This is twice as strange since boost::random is missing mt19937; if it was std:: I'd guess on a non-C++11 standard library, but like it is... If cleaning and rebuilding doesn't help, make sure that libstdc++-devel is correctly installed Basically, it should be right here: http://www.boost.org/doc/libs/1_54_0/boost/random/mersenne_twister.hpp and is included. AAAND bam. Found the bug. header include protection by #ifdef at the very beginning of the file. you might pull my bugfix from https://github.com/marcusmueller/gnuradio.git; git pull https://github.com/marcusmueller/gnuradio.git master_fix_message_strobe_random_ifndef Greetings, Marcus On 02/21/2014 04:00 PM, Ruecan wrote: Thanks Marcus, Actually the boost version I have is 1.54.0. Is this ok ? -- View this message in context:http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46451.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include guard bug
Guys, I re make from clean but still got the same error. PS: after pulling the bugfix, do I need to execute any other command, other than *git pull https://github.com/marcusmueller/gnuradio.git master_fix_message_strobe_random_ifndef * Tim, I did not get what you mean by Tim O'Shea wrote changing headers to use #pragma once -- View this message in context: http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46461.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include guard bug
Well don't worry, it wasn't actually causing problems ;) After fixing, I got out my zsh-foo and tried echo $(( $(git ls-files |grep .h$|xargs git grep --heading #ifndef INCLUDED|wc -l) - $(git ls-files |grep .h$|xargs git grep --heading #ifndef INCLUDED| uniq | wc -l) )) luckily, there are no duplicate lines containing #ifndef INCLUDED, so I'm hopeful enough everything else is fine in current master. I agree on the #pragma once suggestion, and choose to believe http://en.wikipedia.org/wiki/Pragma_once#Portability which says that we should maybe suggest that people move away from gcc 3.4. Although I don't think this would break a relevant numbers of GNU Radio environments, it could be something maintainers might want to save up for 3.8 or 4 ;) Greetings, Marcus On 02/21/2014 05:32 PM, Tim wrote: good find, this was probably my fault - sorry We should consider changing headers to use #pragma once which is simpler and less error prone do people still use gcc older than 3.4 ? I think this is pretty widely supported now not sure if that would cause swig issues as well - -Tim On 02/21/2014 10:51 AM, Marcus Müller wrote: Ruecan: I got carried away. This is indeed a bugfix for the header file not being processed in some cases, but since the error appeared although actually processing the fixed header file, I've run out of ideas, still. On 02/21/2014 04:37 PM, Marcus Müller wrote: Should be :) Just as side info: http://www.boost.org/doc/libs/1_54_0/doc/html/boost/random/mt19937.html Sorry, totally running low on clues here... This is twice as strange since boost::random is missing mt19937; if it was std:: I'd guess on a non-C++11 standard library, but like it is... If cleaning and rebuilding doesn't help, make sure that libstdc++-devel is correctly installed Basically, it should be right here: http://www.boost.org/doc/libs/1_54_0/boost/random/mersenne_twister.hpp and is included. AAAND bam. Found the bug. header include protection by #ifdef at the very beginning of the file. you might pull my bugfix from https://github.com/marcusmueller/gnuradio.git; git pull https://github.com/marcusmueller/gnuradio.git master_fix_message_strobe_random_ifndef Greetings, Marcus On 02/21/2014 04:00 PM, Ruecan wrote: Thanks Marcus, Actually the boost version I have is 1.54.0. Is this ok ? -- View this message in context:http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46451.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include guard bug
Hi Ruecan, this just the question if we should move away from #ifndef INCLUDED_FILENAME_OF_HEADER_H #define INCLUDED_FILENAME_OF_HEADER_H actual header content #endif to the more sanity-ensuring #pragma once preprocessor directive. Sadly, this was not related to your problem... Still have no idea what's causing your problems. Greetings, Marcus On 02/21/2014 05:58 PM, Ruecan wrote: Guys, I re make from clean but still got the same error. PS: after pulling the bugfix, do I need to execute any other command, other than *git pull https://github.com/marcusmueller/gnuradio.git master_fix_message_strobe_random_ifndef * Tim, I did not get what you mean by Tim O'Shea wrote changing headers to use #pragma once -- View this message in context: http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46461.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How does a C++ custom block kill the FlowGraph
Thank you.
I have another question.
I have a strange situation where I have two sub-flowgraphs. The two
sub-flowgraphs are connected by a message queue. The 1st Sink can talk to the
2nd Source through this queue.
TOP BLOCK{
1st subgraph [1st Source]——[…]——[1st Sink]
2nd subgraph [2nd Source] ——[…]——[2nd Sink]
}
Both sub-flowgraphs use the same top block (you can’t have two top blocks in
one application). Unfortunately, because they are disjoint, if the 1st Source
returns WORK_DONE, it won’t call the other blocks’ destructors as I would
expect. It appears that 2nd Source needs to return WORK_DONE as well to kill
it’s subgraph, and thus the entire flow graph.
My problem is that 2nd Source depends on 1st Sink. My original plan was for 1st
Sink to send a message ‘stop’ to 2nd Source, which would then return WORK_DONE
and effectively kill the entire flow graph. Unfortunately, my plan was to do
this in the destructor of 1st Sink, because at that point the 1st’s sink know’s
it’s done processing. This destructor isn’t called until all blocks are done,
so I’ve got a cyclic dependency.
Is it possible for blocks to know if other blocks are done? I could have some
code in my 1st Sink's work function send that ‘stop’ message outside of the
destructor as originally intended.
Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
On Feb 10, 2014, at 12:33 PM, Martin Braun martin.br...@ettus.com wrote:
On 10.02.2014 09:18, Tommy Tracy II wrote:
Dear Gnuradio Community,
I have some custom gnu radio blocks that make up my flow graph. I want
one of my blocks to kill this flow graph (cause all blocks to call their
destructors). When the source is computing its last set of inputs, I
want it to let all the other blocks know it’s time to stop. Ideally,
this source would finish its computation, and allow the sink block to
sink the data before stopping. How would I go about doing this?
Have your block return WORK_DONE (or -1) in the work function.
Note this doesn't call the destructors, though! They get called when your
blocks go out of scope. It makes blocks call their stop(), though.
MB
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-audio OSX fixes test branch
I just pushed the latest WIP for fixing gr-audio on OSX; I hope some adventurous OSX users can test this branch out provide feedback! If you want to help, but don't know how, ask me and I'll provide instructions. - MLD https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx Fixes that I've tested and seem to work for me: + device selection via command line/instantiation arguments (e.g., dial_tone -O foo or audio_fft -I bar); + device selection by full or partial name, case sensitive (for now; e.g., audio_fft -O FUN to get the FUNcube Dongle device); + correct sample rate detection and use for non-Apple provided audio devices (e.g., FUNcube Dongle). Fix that I have not yet tested but should work: + flow-graph start/stop. Fixes that I'm still working on: + if the default audio device is used (meaning, no audio device name is specified at instantiation), then track when the user changes the default audio device and switch to using it; + if a removable device is selected (default or directly), then track if the device is removed and switch to another device. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include guard bug
Do you think that if I go back and try to install GR 3.7.0 instead, it may work ? -- View this message in context: http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46466.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] messages get lost randomly
Hi Guys, I am using the messaging support of basic_block registering the message queue with message_port_register_in and removed the obtained messages with delete_head_blocking. This block is producing streams and everything seems to work fine as long as I consume the messages fast enough. However, if I put a throttle block after my stream producing block, then messages get lost. The producer generates 1 messages with message_port_pub, but the consumer does not receive all of those messages. I intentionally wait 500 ms on the producer for the consumer to be started (otherwise the consumer might not get registered in time). So I have verified that the problem is not in my code, but somewhere the messages get lost. As far as I see in the basic_block code these message queues are not regular msg_queue objects but std::deque objects protected by locks. I do not see how messages could get lost. Any ideas? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Silly bug in gr_fmdet_cf.cc
Just came across a typo in gr_fmdet_cf.cc (compare to previous version to see the correct code). Line 87 currently reads: Sdot = d_scl * (-S0+d_8*S1-d_8*S1+S4); Note that the middle two terms are identical and therefore don't do anything. The correct code should read: Sdot = d_scl * (-S0+d_8*S1-d_8*S3+S4); I am no longer actively working with GR and don't recall how to submit a patch request, plus my version is very old. I'd appreciate somebody putting the patch in for me. Thanks, Eugene Grayver, Ph.D. Aerospace Corp., Sr. Eng. Spec. Tel: 310.336.1274 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] messages get lost randomly
Hi Guys, Ok, I have found out how to make it work reliably. You must register a listener with set_msg_handler, and then you will get the missing messages there. In light of this, I do not see how pdu_to_tagged_stream could work reliably. It does not register a listener (but it does not block either), so if there is a gap in the message stream, then it will miss that message. Miklos On Fri, Feb 21, 2014 at 11:55 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Guys, I am using the messaging support of basic_block registering the message queue with message_port_register_in and removed the obtained messages with delete_head_blocking. This block is producing streams and everything seems to work fine as long as I consume the messages fast enough. However, if I put a throttle block after my stream producing block, then messages get lost. The producer generates 1 messages with message_port_pub, but the consumer does not receive all of those messages. I intentionally wait 500 ms on the producer for the consumer to be started (otherwise the consumer might not get registered in time). So I have verified that the problem is not in my code, but somewhere the messages get lost. As far as I see in the basic_block code these message queues are not regular msg_queue objects but std::deque objects protected by locks. I do not see how messages could get lost. Any ideas? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation fault in qa_constellation_receiver_test
I removed the implementation of volk_malloc that uses posix_menacing by commenting everything from the #if to #else and the final #endif but the segmentation fault remains. I noticed it's being called in a few other files as well. Do I need to remove those, too? Thanks in advance. On Feb 21, 2014 10:21 AM, Kelly Boswell krbosw...@gmail.com wrote: Thank you, Tom. I'll try that after I'm off of work tonight. And thank you for the great ideas, Nathan. On Fri, Feb 21, 2014 at 2:39 AM, West, Nathan n...@ostatemail.okstate.edu wrote: On Thu, Feb 20, 2014 at 11:25 PM, Kelly Boswell krbosw...@gmail.com wrote: After the make test failed for this module, I decided to poke around to see if there is an easy fix. I made a script that simply executes the test over and over until it seg faults and exits after the core file is created. x@:~/src/gnuradio/build/gr-digital/python/digital$ ./runtests.sh Using Volk machine: avx_64_mmx Segmentation fault (core dumped) x@:~/src/gnuradio/build/gr-digital/python/digital$ gdb /usr/bin/python2.7 core (gdb) bt (gdb) bt #0 0x7fe8f627fb17 in volk_32fc_32f_dot_prod_32fc_a_avx () from /home/kelly/src/gnuradio/build/volk/lib/libvolk.so.0.0.0 #1 0x7fe8f52dd25f in gr::filter::kernel::fir_filter_ccf::filter(std::complexfloat const*) () from /home/kelly/src/gnuradio/build/gr-filter/lib/libgnuradio-filter-3.8git.so.0.0.0 #2 0x7fe8f143c45b in gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /home/kelly/src/gnuradio/build/gr-digital/lib/libgnuradio-digital-3.8git.so.0.0.0 #3 0x7fe8f653809e in gr::block_executor::run_one_iteration() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #4 0x7fe8f6573622 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptrgr::block, int) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #5 0x7fe8f6565ea1 in boost::detail::function::void_function_obj_invoker0gr::thread::thread_body_wrappergr::tpb_container, void::invoke(boost::detail::function::function_buffer) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 ---Type return to continue, or q return to quit--- #6 0x7fe8f6526610 in boost::detail::thread_databoost::function0void ::run() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #7 0x7fe8f9adc94a in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 #8 0x7fe8fc8a3f6e in start_thread (arg=0x7fe8e2ffd700) at pthread_create.c:311 #9 0x7fe8fc5ce9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Of course, I had to recompile it with debugging info to glean anything useful from the stack trace. So, I did that and I traced the bug to this line: c0Val = _mm256_mul_ps(a0Val, b0Val); I can't dump the values in a0Val or b0Val, though, because they're intermediate values that are optimized away by the optimized kernel code. I tried stepping through the assembler instructions but I'm not familiar with the various sse and avx extensions. Heck, I'm not even familiar with the x86_64 instruction set. So I have a huge learning curve ahead of me, there. Is it possible to just dump the values in these __m256 data types to a file so I can debug it that way? If that's not easy to do, then I'm willing to learn what I have to about the instruction set so I can debug this thing. But I would sure appreciate some help if anyone has some advice to offer. Software version: I rebased to the latest version of the next branch last night before I went to bed at around 1:30 am CDT. Operating System: kelly@octs2:~/src/gnuradio/volk/kernels/volk$ uname -a Linux octs2 3.11.0-17-generic #31-Ubuntu SMP Mon Feb 3 21:52:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux It's Ubuntu 13.10 Hardware: ASUS X750J Intel Quad Core i7 4700HQ 2.4GHz cpuinfo: processor: 7 vendor_id: GenuineIntel cpu family: 6 model: 60 model name: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz stepping: 3 microcode: 0x8 cpu MHz: 2401.000 cache size: 6144 KB physical id: 0 siblings: 8 core id: 3 cpu cores: 4 apicid: 7 initial apicid: 7 fpu: yes fpu_exception: yes cpuid level: 13 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
Re: [Discuss-gnuradio] segmentation fault in qa_constellation_receiver_test
If you just want to get back to a system that passes QA you should just be able to build off of maint. On Fri, Feb 21, 2014 at 6:05 PM, Kelly Boswell krbosw...@gmail.com wrote: I removed the implementation of volk_malloc that uses posix_menacing by commenting everything from the #if to #else and the final #endif but the segmentation fault remains. I noticed it's being called in a few other files as well. Do I need to remove those, too? Thanks in advance. On Feb 21, 2014 10:21 AM, Kelly Boswell krbosw...@gmail.com wrote: Thank you, Tom. I'll try that after I'm off of work tonight. And thank you for the great ideas, Nathan. On Fri, Feb 21, 2014 at 2:39 AM, West, Nathan n...@ostatemail.okstate.edu wrote: On Thu, Feb 20, 2014 at 11:25 PM, Kelly Boswell krbosw...@gmail.com wrote: After the make test failed for this module, I decided to poke around to see if there is an easy fix. I made a script that simply executes the test over and over until it seg faults and exits after the core file is created. x@:~/src/gnuradio/build/gr-digital/python/digital$ ./runtests.sh Using Volk machine: avx_64_mmx Segmentation fault (core dumped) x@:~/src/gnuradio/build/gr-digital/python/digital$ gdb /usr/bin/python2.7 core (gdb) bt (gdb) bt #0 0x7fe8f627fb17 in volk_32fc_32f_dot_prod_32fc_a_avx () from /home/kelly/src/gnuradio/build/volk/lib/libvolk.so.0.0.0 #1 0x7fe8f52dd25f in gr::filter::kernel::fir_filter_ccf::filter(std::complexfloat const*) () from /home/kelly/src/gnuradio/build/gr-filter/lib/libgnuradio-filter-3.8git.so.0.0.0 #2 0x7fe8f143c45b in gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /home/kelly/src/gnuradio/build/gr-digital/lib/libgnuradio-digital-3.8git.so.0.0.0 #3 0x7fe8f653809e in gr::block_executor::run_one_iteration() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #4 0x7fe8f6573622 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptrgr::block, int) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #5 0x7fe8f6565ea1 in boost::detail::function::void_function_obj_invoker0gr::thread::thread_body_wrappergr::tpb_container, void::invoke(boost::detail::function::function_buffer) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 ---Type return to continue, or q return to quit--- #6 0x7fe8f6526610 in boost::detail::thread_databoost::function0void ::run() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #7 0x7fe8f9adc94a in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 #8 0x7fe8fc8a3f6e in start_thread (arg=0x7fe8e2ffd700) at pthread_create.c:311 #9 0x7fe8fc5ce9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Of course, I had to recompile it with debugging info to glean anything useful from the stack trace. So, I did that and I traced the bug to this line: c0Val = _mm256_mul_ps(a0Val, b0Val); I can't dump the values in a0Val or b0Val, though, because they're intermediate values that are optimized away by the optimized kernel code. I tried stepping through the assembler instructions but I'm not familiar with the various sse and avx extensions. Heck, I'm not even familiar with the x86_64 instruction set. So I have a huge learning curve ahead of me, there. Is it possible to just dump the values in these __m256 data types to a file so I can debug it that way? If that's not easy to do, then I'm willing to learn what I have to about the instruction set so I can debug this thing. But I would sure appreciate some help if anyone has some advice to offer. Software version: I rebased to the latest version of the next branch last night before I went to bed at around 1:30 am CDT. Operating System: kelly@octs2:~/src/gnuradio/volk/kernels/volk$ uname -a Linux octs2 3.11.0-17-generic #31-Ubuntu SMP Mon Feb 3 21:52:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux It's Ubuntu 13.10 Hardware: ASUS X750J Intel Quad Core i7 4700HQ 2.4GHz cpuinfo: processor: 7 vendor_id: GenuineIntel cpu family: 6 model: 60 model name: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz stepping: 3 microcode: 0x8 cpu MHz: 2401.000 cache size: 6144 KB physical id: 0 siblings: 8 core id: 3 cpu cores: 4 apicid: 7 initial apicid: 7 fpu: yes fpu_exception: yes cpuid level: 13 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
Re: [Discuss-gnuradio] segmentation fault in qa_constellation_receiver_test
I'm encountering the same problem on maint. And I did remember to rebuild. I removed the build directory, recreated it, and started over with cmake just to be sure. It's the same stack trace. On Fri, Feb 21, 2014 at 7:54 PM, West, Nathan n...@ostatemail.okstate.eduwrote: If you just want to get back to a system that passes QA you should just be able to build off of maint. On Fri, Feb 21, 2014 at 6:05 PM, Kelly Boswell krbosw...@gmail.com wrote: I removed the implementation of volk_malloc that uses posix_menacing by commenting everything from the #if to #else and the final #endif but the segmentation fault remains. I noticed it's being called in a few other files as well. Do I need to remove those, too? Thanks in advance. On Feb 21, 2014 10:21 AM, Kelly Boswell krbosw...@gmail.com wrote: Thank you, Tom. I'll try that after I'm off of work tonight. And thank you for the great ideas, Nathan. On Fri, Feb 21, 2014 at 2:39 AM, West, Nathan n...@ostatemail.okstate.edu wrote: On Thu, Feb 20, 2014 at 11:25 PM, Kelly Boswell krbosw...@gmail.com wrote: After the make test failed for this module, I decided to poke around to see if there is an easy fix. I made a script that simply executes the test over and over until it seg faults and exits after the core file is created. x@:~/src/gnuradio/build/gr-digital/python/digital$ ./runtests.sh Using Volk machine: avx_64_mmx Segmentation fault (core dumped) x@:~/src/gnuradio/build/gr-digital/python/digital$ gdb /usr/bin/python2.7 core (gdb) bt (gdb) bt #0 0x7fe8f627fb17 in volk_32fc_32f_dot_prod_32fc_a_avx () from /home/kelly/src/gnuradio/build/volk/lib/libvolk.so.0.0.0 #1 0x7fe8f52dd25f in gr::filter::kernel::fir_filter_ccf::filter(std::complexfloat const*) () from /home/kelly/src/gnuradio/build/gr-filter/lib/libgnuradio-filter-3.8git.so.0.0.0 #2 0x7fe8f143c45b in gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /home/kelly/src/gnuradio/build/gr-digital/lib/libgnuradio-digital-3.8git.so.0.0.0 #3 0x7fe8f653809e in gr::block_executor::run_one_iteration() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #4 0x7fe8f6573622 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptrgr::block, int) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #5 0x7fe8f6565ea1 in boost::detail::function::void_function_obj_invoker0gr::thread::thread_body_wrappergr::tpb_container, void::invoke(boost::detail::function::function_buffer) () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 ---Type return to continue, or q return to quit--- #6 0x7fe8f6526610 in boost::detail::thread_databoost::function0void ::run() () from /home/kelly/src/gnuradio/build/gnuradio-runtime/lib/libgnuradio-runtime-3.8git.so.0.0.0 #7 0x7fe8f9adc94a in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 #8 0x7fe8fc8a3f6e in start_thread (arg=0x7fe8e2ffd700) at pthread_create.c:311 #9 0x7fe8fc5ce9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Of course, I had to recompile it with debugging info to glean anything useful from the stack trace. So, I did that and I traced the bug to this line: c0Val = _mm256_mul_ps(a0Val, b0Val); I can't dump the values in a0Val or b0Val, though, because they're intermediate values that are optimized away by the optimized kernel code. I tried stepping through the assembler instructions but I'm not familiar with the various sse and avx extensions. Heck, I'm not even familiar with the x86_64 instruction set. So I have a huge learning curve ahead of me, there. Is it possible to just dump the values in these __m256 data types to a file so I can debug it that way? If that's not easy to do, then I'm willing to learn what I have to about the instruction set so I can debug this thing. But I would sure appreciate some help if anyone has some advice to offer. Software version: I rebased to the latest version of the next branch last night before I went to bed at around 1:30 am CDT. Operating System: kelly@octs2:~/src/gnuradio/volk/kernels/volk$ uname -a Linux octs2 3.11.0-17-generic #31-Ubuntu SMP Mon Feb 3 21:52:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux It's Ubuntu 13.10 Hardware: ASUS X750J Intel Quad Core i7 4700HQ 2.4GHz cpuinfo: processor: 7 vendor_id: GenuineIntel cpu family: 6 model: 60 model name
