Re: [Discuss-gnuradio] installation instructions not working

[Michael Dickens]

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 command issued in 
whatever info you provide, as that can be relevant. Hope this is useful.- MLD

On Tue, Jun 26, 2018, at 3:40 PM, Alejandra Mercado wrote:
> Dear GnuRadio folks,
> 
> I'm following the instructions of 
> 
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
> 
> And I installed the UHD (it found the device, so that seems to be working).
> 
> Now, I'm following the steps under
> Building and installing GNU Radio from source code


> Did this:
> git clone --recursive https://github.com/gnuradio/gnuradio
> Then did this:
> image.png
> Then did this:
> git submodule update --init --recursive
> And when I finally did the  cmake ../     * *_I got this error_**
> 
> image.png
> I'm attaching the two log files it mentions.
> 
> Needless to say, the "make" command won't execute.
> 
> Any ideas where I went wrong?
> 
> Thanks and regards,
> Ale
> _
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> Email had 2 attachments:


>  * CMakeOutput.log
>   130k (text/x-log)
>  * CMakeError.log
>   27k (text/x-log)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[Tom McDermott]

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:https://github.com/Tom-McDermott/gr-hpsdr

Results from gdb:

(gdb) start
Temporary breakpoint 1 at 0x4934c0: file ../Modules/python.c, line 20.
Starting program: /usr/bin/python2 top_block.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=2, argv=0x7fffdfb8)
at ../Modules/python.c:20
20../Modules/python.c: No such file or directory.


(gdb) break std::bad_alloc::what()
Function "std::bad_alloc::what()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (std::bad_alloc::what()) pending.


(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/python2 top_block.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdb463700 (LWP 29362)]
[New Thread 0x7fffdac62700 (LWP 29363)]
[New Thread 0x7fffd6461700 (LWP 29364)]
[New Thread 0x7fffd5c60700 (LWP 29365)]
[New Thread 0x7fffd145f700 (LWP 29366)]
[New Thread 0x7fffcec5e700 (LWP 29367)]
[New Thread 0x7fffce45d700 (LWP 29368)]
[New Thread 0x7fffbbf5b700 (LWP 29369)]
[New Thread 0x7fffbb75a700 (LWP 29370)]
[New Thread 0x7fffbaf59700 (LWP 29371)]
[New Thread 0x7fffabfff700 (LWP 29372)]
[New Thread 0x7fffab7fe700 (LWP 29373)]
[Thread 0x7fffabfff700 (LWP 29372) exited]


   --- this is output from the OOT module, not using docker --
Looking for Metis/Hermes card on interface eth0
Interface[0]:lo  Interface[1]:eth0  Interface[2]:docker0
eth0 IP Address: 192.168.0.2
eth0 MAC Address: 90:b1:1c:6d:00:a7

[New Thread 0x7fffabfff700 (LWP 29375)]

Metis MAC address 00:04:A3:63:F9:8E
Metis IP address 192.168.0.7

gr::log :INFO: audio source - Audio sink arch: alsa
[New Thread 0x7fffa9518700 (LWP 29376)]
[New Thread 0x7fffa8d17700 (LWP 29377)]
[New Thread 0x7fff93ffd700 (LWP 29378)]
[New Thread 0x7fff937fc700 (LWP 29379)]
[New Thread 0x7fff92ffb700 (LWP 29380)]
[New Thread 0x7fff927fa700 (LWP 29381)]
[New Thread 0x7fff91ff9700 (LWP 29382)]
[New Thread 0x7fff917f8700 (LWP 29383)]
[New Thread 0x7fff90ff7700 (LWP 29384)]
[New Thread 0x7fff73fff700 (LWP 29385)]
[New Thread 0x7fff737fe700 (LWP 29386)]
[New Thread 0x7fff72ffd700 (LWP 29387)]
aUQt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Thread 1 "python2" received signal SIGABRT, Aborted.
0x77825428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.


(gdb) info threads
  Id   Target Id Frame
* 1Thread 0x77fb9700 (LWP 29361) "python2" 0x77825428 in
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
  2Thread 0x7fffdb463700 (LWP 29362) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  3Thread 0x7fffdac62700 (LWP 29363) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  4Thread 0x7fffd6461700 (LWP 29364) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  5Thread 0x7fffd5c60700 (LWP 29365) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  6Thread 0x7fffd145f700 (LWP 29366) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  7Thread 0x7fffcec5e700 (LWP 29367) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  8Thread 0x7fffce45d700 (LWP 29368) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  9Thread 0x7fffbbf5b700 (LWP 29369) "dconf worker" 0x778eb74d
in poll () at ../sysdeps/unix/syscall-template.S:84
  10   Thread 0x7fffbb75a700 (LWP 29370) "gmain" 0x778eb74d in poll
()
at ../sysdeps/unix/syscall-template.S:84
  11   Thread 0x7fffbaf59700 (LWP 29371) "gdbus" 0x778eb74d in poll
()
at ../sysdeps/unix/syscall-template.S:84
  13   Thread 0x7fffab7fe700 (LWP 29373) "pool" syscall ()
at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  14   Thread 0x7fffabfff700 (LWP 29375) "python2" 0x77bca8f3 in
recvfrom () at ../sysdeps/unix/syscall-template.S:84
  15   Thread 

[Discuss-gnuradio] Resetting the packet counter in gr-ieee 802.11

[Sumit Kumar]

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 reception.

And then I pass *d_total_packets *thru message port for display and I 
see total packets received like this :




Now I need to reset this frame counter at run time to zero when I check 
a qt-gui-check box. But I am not getting the idea for doing that.


In qt-gui-check box I can make a variable to go true or false. But then 
how to convey this information to the parse_data() function in the 
attached file at run time. A kind of flag which resets d_total_packets 
to 0 without killing the flow graph.


I have attached the parse_mac.cc (line 191) for reference.

Regards

Sumit

/*
 * Copyright (C) 2013, 2016 Bastian Bloessl 
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see .
 */
#include 
#include "utils.h"

#include 
#include 
#include 

using namespace gr::ieee802_11;

class parse_mac_impl : public parse_mac {

public:

parse_mac_impl(bool log, bool debug) :
		block("parse_mac",
gr::io_signature::make(0, 0, 0),
gr::io_signature::make(0, 0, 0)),
		d_log(log), d_last_seq_no(-1), d_total_packets(0),
		d_debug(debug) {

	message_port_register_in(pmt::mp("in"));
	set_msg_handler(pmt::mp("in"), boost::bind(_mac_impl::parse, this, _1));

	message_port_register_out(pmt::mp("fer"));
	message_port_register_out(pmt::mp("tpr"));
}

~parse_mac_impl() {

}

void parse(pmt::pmt_t msg) {

	if(pmt::is_eof_object(msg)) {
		detail().get()->set_done(true);
		return;
	} else if(pmt::is_symbol(msg)) {
		return;
	}

	msg = pmt::cdr(msg);

	int data_len = pmt::blob_length(msg);
	mac_header *h = (mac_header*)pmt::blob_data(msg);

	mylog(boost::format("length: %1%") % data_len );

	dout << std::endl << "new mac frame  (length " << data_len << ")" << std::endl;
	dout << "=" << std::endl;
	if(data_len < 20) {
		dout << "frame too short to parse (<20)" << std::endl;
		return;
	}
	#define HEX(a) std::hex << std::setfill('0') << std::setw(2) << int(a) << std::dec
	dout << "duration: " << HEX(h->duration >> 8) << " " << HEX(h->duration  & 0xff) << std::endl;
	dout << "frame control: " << HEX(h->frame_control >> 8) << " " << HEX(h->frame_control & 0xff);

switch((h->frame_control >> 2) & 3) {

		case 0:
			dout << " (MANAGEMENT)" << std::endl;
			parse_management((char*)h, data_len);
			break;
		case 1:
			dout << " (CONTROL)" << std::endl;
			parse_control((char*)h, data_len);
			break;

		case 2:
			dout << " (DATA)" << std::endl;
			parse_data((char*)h, data_len);
			break;

		default:
			dout << " (unknown)" << std::endl;
			break;
	}

	char *frame = (char*)pmt::blob_data(msg);

	// DATA
	ifh->frame_control) >> 2) & 63) == 2) {
		print_ascii(frame + 24, data_len - 24);
	// QoS Data
	} else ifh->frame_control) >> 2) & 63) == 34) {
		print_ascii(frame + 26, data_len - 26);
	}
}

void parse_management(char *buf, int length) {
	mac_header* h = (mac_header*)buf;

	if(length < 24) {
		dout << "too short for a management frame" << std::endl;
		return;
	}

	dout << "Subtype: ";
	switch(((h->frame_control) >> 4) & 0xf) {
		case 0:
			dout << "Association Request";
			break;
		case 1:
			dout << "Association Response";
			break;
		case 2:
			dout << "Reassociation Request";
			break;
		case 3:
			dout << "Reassociation Response";
			break;
		case 4:
			dout << "Probe Request";
			break;
		case 5:
			dout << "Probe Response";
			break;
		case 6:
			dout << "Timing Advertisement";
			break;
		case 7:
			dout << "Reserved";
			break;
		case 8:
			dout << "Beacon" << std::endl;
			if(length < 38) {
return;
			}
			{
			uint8_t* len = (uint8_t*) (buf + 24 + 13);
			if(length < 38 + *len) {
return;
			}
			std::string s(buf + 24 + 14, *len);
			dout << "SSID: " << s;
			}
			break;
		case 9:
			dout << "ATIM";
			break;
		case 10:
			dout << "Disassociation";
			break;
		case 11:
			dout << "Authentication";
			break;
		case 12:
			dout << "Deauthentication";
			break;
		case 13:
			dout << "Action";
			break;
		case 14:
			dout << "Action No ACK";
			break;
		case 15:
			dout << "Reserved";
			break;
		default:
			break;
	}
	dout << std::endl;

	dout << "seq nr: " << int(h->seq_nr >> 4) << 

Re: [Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[CEL]

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 about the same thing.
* I assume you've got GNU Radio built with debug symbols (cmake
-DCMAKE_BUILD_TYPE=RelWithDebInfo). This might even work if it wasn't,
but the backtraces below might be less exciting.
* you'll need gdb

gdb --args python2 /path/to/your/flowgraph.py⏎

(things flutter by)

(gdb)start⏎

(things flutter by)

(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`)

(gdb)run⏎

(wait for the breakpoint defined above to trigger)

(gdb)info threads⏎

(this is the list of currently existing threads. Copy and save.)

(gdb)bt⏎

(short for `backtrace`. Now we should be getting a list that's
basically like "walking an onion from the middle to the peel", if
you're onion layers are defined by who called a function which called a
function...)

Share the output; if you look through it, the frame with the lowest
number that already happens somewhere inside libgnuradio-qtgui probably
contains info on where exactly that allocation happens that fails.

You can "jump" into that frame with `frame `, replacing
 with the index given by # in the backtrace. If these
variables/symbols weren't optimized away during compilation, you can
even use `print ` to print the values of local and global
variables, or use `list` to print the source code of what you're
looking at (that definitely requires debug info to be included with GNU
Radio's build).

Best regards,
Marcus

On Mon, 2018-06-25 at 16:52 -0700, Tom McDermott wrote:
> Ubuntu 16.04.3
> GRC 3.7.11.1   (from git)
> I was on 3.7.13 couple of weeks ago, completely removed all of
> gnuradio
> and rebuilt trying to debug this.  3.7.11.1 had same problem.
> 
> 
> Got back to the problem of several weeks ago.
> 
> 1. When I try to use a QT GUI sink (such as frequency) the invocation
> of
> the QT Gui Frequency sink in this example throws a memory allocation
> error.
> 
> Qt has caught an exception thrown from an event handler. Throwing
> exceptions from an event handler is not supported in Qt. You must
> reimplement QApplication::notify() and catch all exceptions there.
> 
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc
> 
> 2. If I remove the Row, Column GUI hints from just that one QT GUI
> item, then it
> comes up and runs OK. The other 9 of the QT controls (sliders,
> choosers, entry,
> ranges) still have their R,C hints.
> 
> 3. Went back to the GRC file in step 1 that still has the R,C hints
> in it
> and it still fails with the error as shown in step 1.  It did come up
> and run
> one time showing 'unable to set locale' error, but still ran.  Never
> seen that before.
> 
> 
> Is there some limitation against using R,C hints on the QT displays
> (time,
> frequency, etc.)?
> 
> -- Tom, N5EG
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[CEL]

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 point it's totally OK to complain about missing
symbol. Just say it's OK to set the breakpoint on future library load.


On Tue, 2018-06-26 at 10:47 +, Müller, Marcus (CEL) wrote:
> 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 about the same thing.
> * I assume you've got GNU Radio built with debug symbols (cmake
> -DCMAKE_BUILD_TYPE=RelWithDebInfo). This might even work if it
> wasn't,
> but the backtraces below might be less exciting.
> * you'll need gdb
> 
> gdb --args python2 /path/to/your/flowgraph.py⏎
> 
> (things flutter by)
> 
> (gdb)start⏎
> 
> (things flutter by)
> 
> (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`)
> 
> (gdb)run⏎
> 
> (wait for the breakpoint defined above to trigger)
> 
> (gdb)info threads⏎
> 
> (this is the list of currently existing threads. Copy and save.)
> 
> (gdb)bt⏎
> 
> (short for `backtrace`. Now we should be getting a list that's
> basically like "walking an onion from the middle to the peel", if
> you're onion layers are defined by who called a function which called
> a
> function...)
> 
> Share the output; if you look through it, the frame with the lowest
> number that already happens somewhere inside libgnuradio-qtgui
> probably
> contains info on where exactly that allocation happens that fails.
> 
> You can "jump" into that frame with `frame `, replacing
>  with the index given by # in the backtrace. If these
> variables/symbols weren't optimized away during compilation, you can
> even use `print ` to print the values of local and
> global
> variables, or use `list` to print the source code of what you're
> looking at (that definitely requires debug info to be included with
> GNU
> Radio's build).
> 
> Best regards,
> Marcus
> 
> On Mon, 2018-06-25 at 16:52 -0700, Tom McDermott wrote:
> > Ubuntu 16.04.3
> > GRC 3.7.11.1   (from git)
> > I was on 3.7.13 couple of weeks ago, completely removed all of
> > gnuradio
> > and rebuilt trying to debug this.  3.7.11.1 had same problem.
> > 
> > 
> > Got back to the problem of several weeks ago.
> > 
> > 1. When I try to use a QT GUI sink (such as frequency) the
> > invocation
> > of
> > the QT Gui Frequency sink in this example throws a memory
> > allocation
> > error.
> > 
> > Qt has caught an exception thrown from an event handler. Throwing
> > exceptions from an event handler is not supported in Qt. You must
> > reimplement QApplication::notify() and catch all exceptions there.
> > 
> > terminate called after throwing an instance of 'std::bad_alloc'
> >   what():  std::bad_alloc
> > 
> > 2. If I remove the Row, Column GUI hints from just that one QT GUI
> > item, then it
> > comes up and runs OK. The other 9 of the QT controls (sliders,
> > choosers, entry,
> > ranges) still have their R,C hints.
> > 
> > 3. Went back to the GRC file in step 1 that still has the R,C hints
> > in it
> > and it still fails with the error as shown in step 1.  It did come
> > up
> > and run
> > one time showing 'unable to set locale' error, but still
> > ran.  Never
> > seen that before.
> > 
> > 
> > Is there some limitation against using R,C hints on the QT displays
> > (time,
> > frequency, etc.)?
> > 
> > -- Tom, N5EG
> > 
> > 
> > 
> > 
> > ___
> > 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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio