Application that reproduces segfault:
http://pastebin.com/Fw0y7qM9
debug backtrace: http://pastebin.com/FjnHu6Cs
patch that fixes it for me, although I'm sure theres a better place to fix
it: http://pastebin.com/4gSW57Wt
Thanks,
Matt.
___
I was getting both, however moving to a physical platform (instead of VM)
seems to have resolved a few isues, the control problems are still an
issue. I'll see if I can pull the new branch and try the new driver.
On Tue, Jul 10, 2012 at 3:57 PM, Josh Blum j...@ettus.com wrote:
But I'm not sure
On Mon, Jun 11, 2012 at 1:19 PM, Josh Blum j...@ettus.com wrote:
Alright, I am getting out my big hammer. Not only will this code be
fixed, but a new feature will be added!
-josh
Hi Josh,
Has the big hammer been acquired? I still get these control errors all the
time, requiring manual
On Tue, Jan 3, 2012 at 10:36 AM, Ben Hilburn b...@ettus.com wrote:
But you should not have to 'try it twice', unless something about your USB
driver or OS is broken.
FYI I was seeing the try it twice behaviour consistently with VMware;
probably because it has to reconnect the device to the
On Thu, Dec 29, 2011 at 9:27 AM, Andrew Davis glneolistm...@gmail.comwrote:
It's going to have to be part of UHD because a lot of programs I'm having
problems with are not using GNUradio, they just read from UHD.
It seems like there is a lot of effort going into fixing problems with bad
Any chance it could be recorded or webcast for those of us a tad further
away?
On Mon, Dec 19, 2011 at 12:20 PM, Tom Rondeau trondeau1...@gmail.comwrote:
Hey everyone,
I just wanted to let everyone know that I will be speaking at the new
Software Radio Implementation Forum's (SRIF) first
All,
I'm willing to offer a 100$ bounty on a patch that fixes the GNUradio
lockup in the attached script (basically just running lock() unlock() in a
loop).
Thanks,
Matt.
-- Forwarded message --
From: Matt Mills mmi...@2bn.net
Date: Fri, Dec 9, 2011 at 9:02 AM
Subject: Re
On Mon, Dec 12, 2011 at 10:52 AM, Martin Braun martin.br...@kit.edu wrote:
Yes, that makes sense. Try this (is the same as what I sent to
patch-gnuradio). It works with your script.
FYI, I've run this for the past 24 hours (on the production app, not the
test script) and haven't seen any
I saw him selling an N210 one week, then the next he was trying to sell an
N210 + some Micro ATX machine for 2400$; I figured it was a scam after that
one...
On Mon, Dec 12, 2011 at 9:59 AM, dave k dave_k_...@yahoo.com wrote:
what a nice holiday surprise
anyone else buy a n210 from seller
On Mon, Dec 12, 2011 at 3:41 AM, Martin Braun martin.br...@kit.edu wrote:
* Do you randomly get either segfault or i/o error? I always get the i/o
with this code..
I get both.
* Your code stresses the WAV-code a lot :) What are you trying to
accomplish? Are you finding a bug in
On Mon, Dec 12, 2011 at 10:47 AM, Martin Braun martin.br...@kit.edu wrote:
On Mon, Dec 12, 2011 at 11:49:56AM +0100, Martin Braun wrote:
On Sun, Dec 11, 2011 at 02:31:03PM -0500, Marcus D. Leech wrote:
I think that what I'd do is cause the close() method to simply set a
flag that
says
On Mon, Dec 12, 2011 at 10:57 AM, Matt Mills mmi...@2bn.net wrote:
But wont this only close() a file when the sink is receiving samples? I
would think it would be extremely confusing if close() doesnt actually
close a file until the next sample is received, especially if there is a
valve
All,
The attached script crashes with a segmentation fault (or with the I/O
error text in the code). My C++ knowledge is lacking however I believe this
is because work() and close() are both being called simultaneously from
different threads. The close() call is being made while the execution of
If there is no samples flowing into the wav file sink block would work() be
called? (IE, if there is a closed valve in front of the wav_file sink)
On Sun, Dec 11, 2011 at 12:31 PM, Marcus D. Leech mle...@ripnet.com wrote:
**
I think that what I'd do is cause the close() method to simply set a
2011/12/8 Dan CaJacob d...@spacequest.com
Hi Kouki,
I don't think you will see the signal in an FFT window. GPS is spread
spectrum and the signal is below the noise floor. But the signal is
still decodable.
I thought this was the case; but as someone without any DSP experience this
boggles
On Wed, Dec 7, 2011 at 3:27 PM, Matt Mills mmi...@2bn.net wrote:
*frowns at ubuntu*
After updating to Ubuntu 11.10 (which has boost 1.46) I still experience
the lockup.
linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-7dc76db
___
Discuss
On Thu, Dec 8, 2011 at 2:05 PM, Matt Mills mmi...@2bn.net wrote:
After updating to Ubuntu 11.10 (which has boost 1.46) I still experience
the lockup.
Also, Here's the python I've been using to reproduce:
http://pastebin.com/at0FdzXp
and the GDB backtrace after its locked up: http
On Thu, Dec 8, 2011 at 11:02 PM, Johnathan Corgan
jcor...@corganenterprises.com wrote:
It's possible that whatever thread is being interrupted is somewhere in an
uninterruptible state, though I'm not sure what that could be. If you
could do an info threads in gdb, that might shed some light.
On Thu, Dec 8, 2011 at 11:15 PM, Matt Mills mmi...@2bn.net wrote:
With an even simpler version of the app (signal - null sink) just running
lock() unlock() in the loop it still locks up; using that version gives
this info from gdb (info threads, and bt on both threads included)
http
On Tue, Dec 6, 2011 at 4:00 PM, Tom Rondeau trondeau1...@gmail.com wrote:
What OS are you running?
(I'm asking these questions because I'm stumped and am buying time.)
I did the same thing in #gnuradio ;) I believe it was slackware.
___
Has anyone had time to look into the unlock() lockup that Rachel reproduced
below further? I seem to be running into it left and right for some reason
and sadly my C++ isnt anywhere near good enough to go seeking the cause
myself.
On Tue, Nov 22, 2011 at 9:02 AM, Rachel Kroll
On Wed, Dec 7, 2011 at 10:00 AM, Don Ward don2387w...@sprynet.com wrote:
This looks like an old boost problem (
https://svn.boost.org/trac/boost/ticket/2330). Is there any chance you
are using a version of boost older than 1.45?
*frowns at ubuntu*
ii libboost1.40-dev
1.40.0-4ubuntu4
It appears UHD does not like to be watched; reproducibly if I run with GDB
attached, UHD eventually stops sending data to the upstream blocks and my
screen fills up with:
thread[single-threaded-scheduler]: RuntimeError: Control channel send error
thread[single-threaded-scheduler]: RuntimeError:
Curiously at startup python begins consuming ~1950M of VIRT, but only 46M
of RES and 23M of SHR... No signs of any of those numbers increasing more
than +/- 5% (although VIRT occasionally drops momentarily to ~160-180 MB
before returning to ~1950 MB which seems awfully strange).
About 15 minutes
On Tue, Nov 22, 2011 at 6:52 AM, Mark Steward markstew...@gmail.com wrote:
I've seen lockups of this sort when multi-threaded python processes exit.
You might also like to take a look at what each thread is up to in gdb.
I'm not really sure how to get around in GDB, but I've captured a
Ubuntu 10.04 LTS (x86) on a physical desktop (intel G6950 dual core CPU), 2
GB physical ram, 6 GB swap space, OS is up to date per apt. Gnuradio and
UHD are both built from git as of yesterday.
Linux -hostname- 2.6.32-35-generic-pae #78-Ubuntu SMP Tue Oct 11 17:01:12
UTC 2011 i686 GNU/Linux
On
This graph doesnt have any unlock/locks in the code itself, it does use
valve blocks (which I believe use unlock/lock internally) which are used to
mute/unmute streams (there is probably an average of 2-4 valve state
changes per second across the graphs 19 valves).
On Tue, Nov 22, 2011 at 8:39
I may have also neglected to mention that this graph, by my count, has
about 197 blocks in it...
So is their anything I could look at further in my app (aside from trying
to eliminate the valve blocks, which I'm attempting to do) that I could
positively determine the cause of the lockups (and if
On Tue, Nov 22, 2011 at 11:28 AM, Philip Balister phi...@balister.orgwrote:
You can use the single threaded scheduler by setting an environment
variable:
export GR_SCHEDULER=STS
Gave this a shot; app runs for a while (at 100% CPU with quite a few
overruns) then segfaults...
[20077.594080]
On Tue, Nov 22, 2011 at 8:30 PM, Marcus D. Leech mle...@ripnet.com wrote:
**
It's a big flow-graph (you'd mentioned 197 blocks), so it will be a pain
to whittle down exactly *which* block is causing the segfault--and it's
provoking it from inside libc, which makes it even less fun.
While
Hello all,
I seem to be having an issue that, after about 30-45 minutes of running
normally my gnuradio based python app will just lock up. It wont respond to
control C, it holds all of its existing file handles open but doesnt do
anything with them, and an strace attach shows only:
31 matches
Mail list logo
