[Discuss-gnuradio] GNURadio segmentation fault
Dear All, I have been running GNURadio fairly constantly for a couple of weeks now using simple_ra although, I don't believe it is a problem with that application as HTOP doesn't indicate memory issues etc. I run GNURadio version 3.7.9.1 on an Intel® Core™ i7-2600 CPU @ 3.40GHz × 8. I have been running Ubuntu 14.04 LTS for years now but on encountering the issue recently with continuous GNURadio use, I upgraded to 15.10 but the problem still occurs. Here is what they syslog(s) say: previous (for years!) 14.04LTS May 7 15:01:34 i7Ubuntu kernel: [59309.794629] python2[3772]: segfault at 0 ip 7f8e53be91c0 sp 7ffe66518cc8 error 6 in libc-2.19.so[7f8e53b51000+1bb000] May 11 02:06:54 i7Ubuntu kernel: [97164.418968] python2[2735]: segfault at 0 ip 7fbc2dce61c0 sp 7ffdd22fa0a8 error 6 in libc-2.19.so[7fbc2dc4e000+1bb000] upgraded to 15.10 May 21 22:22:12 i7Ubuntu kernel: [643331.441347] python2[24419]: segfault at 0 ip 7faee89160e0 sp 7ffc3857e748 error 6 in libc-2.21.so[7faee8876000+1c] May 22 05:36:28 i7Ubuntu kernel: [21018.530748] python2[2408]: segfault at 0 ip 7ff267bcb882 sp 7ffdfe2d0b90 error 6 in i965_dri.so[7ff267814000+5b2000] I get no other symptoms i.e. no D's or anything bad reported by UHD. I also don't get problems with any other applications to indicate some memory issue though I wouldn't expect the regular apps to use as much memory - mind you when running simple_ra uses less than 10% of the memory. Any ideas on how I can narrow the cause down? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio segmentation fault
Hi John, I don't really know about the memory usage you see, but: Did you rebuild GNU Radio (and UHD and basically everything you did not install directly through Ubuntu's apt-get)? Upgrading a distro often changes the libc version used, and that might mean that the ABI of the very core functionality has changed, and your program is calling functions with the wrong parameters or functions that don't exist. That would be my first guess. Now, you said you upgraded in an attempt to remedy those failures, so I'm fully aware that might not be the /right/ guess, but segfaults in libc usually only happen if you call some system functionality with a non-existing / too short buffer or invalid pointer to a structure or something like that, and the most common cause for that (aside from actual bugs, but I'm not aware of anything currently, but I haven't really used simple_ra much) would be an ABI mismatch. Now, this isn't going to fix if something in simple_ra actually segfaults: So, my first attempt would really be a make clean; make; (sudo) make install . If that fails, run your simple_ra application through GDB. The trick here would probably be (Marcus L., you shout if I say something stupid, right?) to modify the simple_ra script; at the very end, replace simple_ra_receiver.py --frequency ... by gdb -ex run --args python2 simple_ra_receiver --frequency ... to let gdb run the python flow graph for you. Then, at some point gdb should catch the segfault and drop you to a command prompt; "bt" or "backtrace" is the command you want to do to see the cascade of calls going on (it might be helpful to have installed the "xyz-dbg" packages for Ubuntu's python and libc packages, and build your GNU Radio with debug symbols enabled, i.e. using -DCMAKE_BUILD_TYPE=RelWithDebInfo when calling cmake) when the segfault happened. Often, that's already sufficient to narrow down the bug. If it isn't: the lines of the backtrace start with a #number; that number is the frame number, and you can change into each frame, do a "list" (if debug symbols are present) and get the source code where the program currently is, use "print" to print variables (really invaluable if you've e.g. got a "for" loop that keeps on writing past the end of a buffer and you don't know why). Best regards, Marcus On 22.05.2016 09:18, John Shields wrote: > Dear All, > I have been running GNURadio fairly constantly for a > couple of weeks now using simple_ra although, I don't believe it is a > problem with that application as HTOP doesn't indicate memory issues etc. > > I run GNURadio version 3.7.9.1 on an Intel® Core™ i7-2600 > CPU @ 3.40GHz × 8. > > I have been running Ubuntu 14.04 LTS for years now but on > encountering the issue recently with continuous GNURadio use, I > upgraded to 15.10 but the problem still occurs. > > Here is what they syslog(s) say: > > previous (for years!) 14.04LTS > > May 7 15:01:34 i7Ubuntu kernel: [59309.794629] python2[3772]: > segfault at 0 ip 7f8e53be91c0 sp 7ffe66518cc8 error 6 in > libc-2.19.so[7f8e53b51000+1bb000] > > May 11 02:06:54 i7Ubuntu kernel: [97164.418968] python2[2735]: > segfault at 0 ip 7fbc2dce61c0 sp 7ffdd22fa0a8 error 6 in > libc-2.19.so[7fbc2dc4e000+1bb000] > > upgraded to 15.10 > > May 21 22:22:12 i7Ubuntu kernel: [643331.441347] python2[24419]: > segfault at 0 ip 7faee89160e0 sp 7ffc3857e748 error 6 in > libc-2.21.so[7faee8876000+1c] > > May 22 05:36:28 i7Ubuntu kernel: [21018.530748] python2[2408]: > segfault at 0 ip 7ff267bcb882 sp 7ffdfe2d0b90 error 6 in > i965_dri.so[7ff267814000+5b2000] > > I get no other symptoms i.e. no D's or anything bad > reported by UHD. > > I also don't get problems with any other applications to > indicate some memory issue though I wouldn't expect the regular apps > to use as much memory - mind you when running simple_ra uses less than > 10% of the memory. > > Any ideas on how I can narrow the cause down? > >Kind Regards, > >John > > ___ > 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] GNURadio segmentation fault
On 05/22/2016 05:19 AM, Marcus Müller wrote: Hi John, I don't really know about the memory usage you see, but: Did you rebuild GNU Radio (and UHD and basically everything you did not install directly through Ubuntu's apt-get)? Upgrading a distro often changes the libc version used, and that might mean that the ABI of the very core functionality has changed, and your program is calling functions with the wrong parameters or functions that don't exist. That would be my first guess. Now, you said you upgraded in an attempt to remedy those failures, so I'm fully aware that might not be the /right/ guess, but segfaults in libc usually only happen if you call some system functionality with a non-existing / too short buffer or invalid pointer to a structure or something like that, and the most common cause for that (aside from actual bugs, but I'm not aware of anything currently, but I haven't really used simple_ra much) would be an ABI mismatch. Now, this isn't going to fix if something in simple_ra actually segfaults: So, my first attempt would really be a make clean; make; (sudo) make install . If that fails, run your simple_ra application through GDB. The trick here would probably be (Marcus L., you shout if I say something stupid, right?) to modify the simple_ra script; at the very end, replace simple_ra_receiver.py --frequency ... by gdb -ex run --args python2 simple_ra_receiver --frequency ... to let gdb run the python flow graph for you. Then, at some point gdb should catch the segfault and drop you to a command prompt; "bt" or "backtrace" is the command you want to do to see the cascade of calls going on (it might be helpful to have installed the "xyz-dbg" packages for Ubuntu's python and libc packages, and build your GNU Radio with debug symbols enabled, i.e. using -DCMAKE_BUILD_TYPE=RelWithDebInfo when calling cmake) when the segfault happened. Often, that's already sufficient to narrow down the bug. If it isn't: the lines of the backtrace start with a #number; that number is the frame number, and you can change into each frame, do a "list" (if debug symbols are present) and get the source code where the program currently is, use "print" to print variables (really invaluable if you've e.g. got a "for" loop that keeps on writing past the end of a buffer and you don't know why). Best regards, Marcus It's conceivable that this is simple_ra's fault. While it's almost-entirely written in GRC with some helper Python, there are some custom blocks used from gr-ra_blocks, written in C++. I'd be interested to know if the failure is actually from one of those... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Non-uniform behaviour of swigged objects (was: [USRP-users] uhd.tune_request always returns 0)
Well, the python semantics, at least as I understand them, dictate that
"not objectname" is True if objectname is of NoneType, or if objectname
is actually False, or evaluates to something that is False (i.e. 0).
A valid object "should be".
Checking it against the typical swigged GNU Radio objects:
$from gnuradio import blocks, uhd
$vs = blocks_vector_sink_b()
$f = uhd.tune_request(10)
$bool(vs)
True
$bool(f)
False
That's non-uniform behaviour, and it surprises me!
I'll have to meditate about this.
Best regards,
Marcus
On 22.05.2016 17:51, Marcus D. Leech via USRP-users wrote:
> On 05/22/2016 11:46 AM, Marcus Müller via USRP-users wrote:
>> Hm, interesting. I shouldn't have thought so, but: /something's/
>> strange, and for some reason, perfectly valid uhd.tune_request
>> objects evaluate to False in this case.
>>
>> So: since there's hardly any case that you can mis-construct a tune
>> request (any frequency that is numerical should be fine, even
>> negative numbers), I'd say: drop your "if not tx_center_freq" clause
>> and just check whether the properties of the uhd.tune_result that
>> tx.set_center_freq() return match your expectation.
>>
>> Best regards,
>> Marcus
> What are the boolean semantics of a structured data type like a
> tune_request_t ? It's not immediately clear to me that there is a mapping
> in boolean for such structured data types.
>
>
>>
>> On 22.05.2016 17:32, Elvis Angelaccio via USRP-users wrote:
>>> Hi, can someone explain me why `uhd.tune_request` always returns 0 in
>>> the following Python code?
>>> I'm running this on Linux with a USRP1 attached via USB.
>>> The USRP has two 900 MHz daughterboards and two antennas attached to
>>> TX/RX ports.
>>>
>>> Gnuradio version = 3.7.9.2
>>> UHD version = 3.9.3
>>>
>>> ### CODE Snippet
>>>
>>> d = uhd.find_devices(uhd.device_addr(args.address_args))
>>> if d:
>>> print 'Available UHD devices: ' + str(d)
>>>
>>> try:
>>> uhd_type = d[0].get('type')
>>> except IndexError:
>>> print 'Fatal error. Did you connect the USRP to an USB port?'
>>> sys.exit(1)
>>>
>>> serial = d[0].get('serial')
>>> tx = uhd.usrp_sink(
>>> device_addr='serial=' + serial,
>>> stream_args=uhd.stream_args(
>>> 'fc32',
>>> channels=range(1)
>>> )
>>> )
>>>
>>> tx_center_freq = uhd.tune_request(freq)
>>>
>>> if not tx_center_freq: # <= Always happening.
>>> print 'Could not set TX freq'
>>> sys.exit(1)
>>>
>>> tx.set_center_freq(tx_center_freq)
>>> ...
>>>
>>>
>>> Best regards,
>>> Elvis
>>>
>>> ___
>>> USRP-users mailing list
>>> usrp-us...@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Non-uniform behaviour of swigged objects
ha! uhd.tune_request (and others, like sensor_value) python objects have
a __nonzero__ method, which is inherently used for conversion to bool,
if present. And guess what: they return False.
Wondering where they come from.
Cheers,
Marcus
On 22.05.2016 18:02, Marcus Müller wrote:
> Well, the python semantics, at least as I understand them, dictate
> that "not objectname" is True if objectname is of NoneType, or if
> objectname is actually False, or evaluates to something that is False
> (i.e. 0).
>
> A valid object "should be".
>
> Checking it against the typical swigged GNU Radio objects:
>
> $from gnuradio import blocks, uhd
> $vs = blocks_vector_sink_b()
> $f = uhd.tune_request(10)
> $bool(vs)
> True
> $bool(f)
> False
>
> That's non-uniform behaviour, and it surprises me!
>
> I'll have to meditate about this.
>
> Best regards,
> Marcus
>
> On 22.05.2016 17:51, Marcus D. Leech via USRP-users wrote:
>> On 05/22/2016 11:46 AM, Marcus Müller via USRP-users wrote:
>>> Hm, interesting. I shouldn't have thought so, but: /something's/
>>> strange, and for some reason, perfectly valid uhd.tune_request
>>> objects evaluate to False in this case.
>>>
>>> So: since there's hardly any case that you can mis-construct a tune
>>> request (any frequency that is numerical should be fine, even
>>> negative numbers), I'd say: drop your "if not tx_center_freq" clause
>>> and just check whether the properties of the uhd.tune_result that
>>> tx.set_center_freq() return match your expectation.
>>>
>>> Best regards,
>>> Marcus
>> What are the boolean semantics of a structured data type like a
>> tune_request_t ? It's not immediately clear to me that there is a
>> mapping
>> in boolean for such structured data types.
>>
>>
>>>
>>> On 22.05.2016 17:32, Elvis Angelaccio via USRP-users wrote:
Hi, can someone explain me why `uhd.tune_request` always returns 0 in
the following Python code?
I'm running this on Linux with a USRP1 attached via USB.
The USRP has two 900 MHz daughterboards and two antennas attached to
TX/RX ports.
Gnuradio version = 3.7.9.2
UHD version = 3.9.3
### CODE Snippet
d = uhd.find_devices(uhd.device_addr(args.address_args))
if d:
print 'Available UHD devices: ' + str(d)
try:
uhd_type = d[0].get('type')
except IndexError:
print 'Fatal error. Did you connect the USRP to an USB port?'
sys.exit(1)
serial = d[0].get('serial')
tx = uhd.usrp_sink(
device_addr='serial=' + serial,
stream_args=uhd.stream_args(
'fc32',
channels=range(1)
)
)
tx_center_freq = uhd.tune_request(freq)
if not tx_center_freq: # <= Always happening.
print 'Could not set TX freq'
sys.exit(1)
tx.set_center_freq(tx_center_freq)
...
Best regards,
Elvis
___
USRP-users mailing list
usrp-us...@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> usrp-us...@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio segmentation fault
On 22/05/16 11:06, Marcus D. Leech wrote: On 05/22/2016 05:19 AM, Marcus Müller wrote: Hi John, I don't really know about the memory usage you see, but: Did you rebuild GNU Radio (and UHD and basically everything you did not install directly through Ubuntu's apt-get)? Upgrading a distro often changes the libc version used, and that might mean that the ABI of the very core functionality has changed, and your program is calling functions with the wrong parameters or functions that don't exist. That would be my first guess. Now, you said you upgraded in an attempt to remedy those failures, so I'm fully aware that might not be the /right/ guess, but segfaults in libc usually only happen if you call some system functionality with a non-existing / too short buffer or invalid pointer to a structure or something like that, and the most common cause for that (aside from actual bugs, but I'm not aware of anything currently, but I haven't really used simple_ra much) would be an ABI mismatch. Now, this isn't going to fix if something in simple_ra actually segfaults: So, my first attempt would really be a make clean; make; (sudo) make install . If that fails, run your simple_ra application through GDB. The trick here would probably be (Marcus L., you shout if I say something stupid, right?) to modify the simple_ra script; at the very end, replace simple_ra_receiver.py --frequency ... by gdb -ex run --args python2 simple_ra_receiver --frequency ... to let gdb run the python flow graph for you. Then, at some point gdb should catch the segfault and drop you to a command prompt; "bt" or "backtrace" is the command you want to do to see the cascade of calls going on (it might be helpful to have installed the "xyz-dbg" packages for Ubuntu's python and libc packages, and build your GNU Radio with debug symbols enabled, i.e. using -DCMAKE_BUILD_TYPE=RelWithDebInfo when calling cmake) when the segfault happened. Often, that's already sufficient to narrow down the bug. If it isn't: the lines of the backtrace start with a #number; that number is the frame number, and you can change into each frame, do a "list" (if debug symbols are present) and get the source code where the program currently is, use "print" to print variables (really invaluable if you've e.g. got a "for" loop that keeps on writing past the end of a buffer and you don't know why). Best regards, Marcus It's conceivable that this is simple_ra's fault. While it's almost-entirely written in GRC with some helper Python, there are some custom blocks used from gr-ra_blocks, written in C++. I'd be interested to know if the failure is actually from one of those... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thank you Marcus'. I used Marcus(L) build script to get UHD/GNURadio so I will do the :make clean etc. that is suggested. You can see from the syslog that, the upgrade to 15.10 did, indeed, bump the revision of libc. That was a good tip re: modifying the simple_ra run script to put GDB in first. Will run in that mode and let you know what I get. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [PyBOMBS] Need your help!
Hi, > My prime test case is the following pybombs command: > > $ pybombs prefix init ~/path/to/prefix -R gnuradio-default > > (Note you will need the most current PyBOMBS and gr-recipes to run this). I just gave this a shot, but I aborted pretty quickly. It started building alsa from sources ... Ideally I'd like to only build from source the SDR related packages that don't have any decent version available as package and not every package. Also since I run pybombs as user and not root (no way I'm building all of this as the root user ...), I don't expect pybomb to install the packages, but I would expect it to list them to me so I can install them myself then restart pybombs. Anyway, just my 2 ct ... Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [PyBOMBS] Need your help!
Hi Sylvain, what platform are you on? (basically, libalsa should be installed via package whenever possible, which is the case on debian, ubuntu, fedora and centos, I thought) Also: I kind of like the "don't install, just list" idea. However, Pybombs would never encourage you to build stuff as root – super user privileges are acquired as necessary through sudo. Cheers, Marcus On 22.05.2016 23:32, Sylvain Munaut wrote: > Hi, > >> My prime test case is the following pybombs command: >> >> $ pybombs prefix init ~/path/to/prefix -R gnuradio-default >> >> (Note you will need the most current PyBOMBS and gr-recipes to run this). > I just gave this a shot, but I aborted pretty quickly. > > It started building alsa from sources ... > > Ideally I'd like to only build from source the SDR related packages > that don't have any decent version available as package and not every > package. > Also since I run pybombs as user and not root (no way I'm building all > of this as the root user ...), I don't expect pybomb to install the > packages, but I would expect it to list them to me so I can install > them myself then restart pybombs. > > Anyway, just my 2 ct ... > > > Cheers, > >Sylvain > > ___ > 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
