Re: Volk error

Thanks that kind of worked for me it showed the gui for a while but then
it
stopped with following error :

GRAS: The debug asserts are enabled. <<<
Created default thread pool with 4 threads.
Using Volk machine: sse4_2_32_orc
ASSERT FAIL
/home/electron/Downloads/gras/lib/gras_impl/input_buffer_queues.hpp:156
total_idle_times[i] <= (time_now() - _init_time)
terminate called after throwing an instance of ‘std::runtime_error’
what(): ASSERT FAIL total_idle_times[i] <= (time_now() - _init_time)

On 06/11/2013 03:55 PM, Yogesh Dahiya wrote:

what(): ASSERT FAIL total_idle_times[i] <= (time_now() - _init_time)

So I dont completely understand the nature of the problem. If you give
me some feedback, I think that its something pretty simple. Possibly an
issuing with using the getclocktime CLOCK_MONOTONIC.

Can you tell me your OS name and version, 32 or 64 bit?

If you pull and rebuild, there is a unit test for the timer stuff, I
wonder what the output verbose is. Can you run this in the build
directory: tests/chrono_time_test_cpp_test.sh

If you apply this diff and rebuild, I think that the additional prints
will be very revealing: http://pastebin.com/xeBHFN5j

-josh

I have ubuntu 11.10 32 bit system
output of the unit test is

Running 1 test case…
t0 1804958425
t1 2805093589
delta_time 1.00014

*** No errors detected

After applying the diff :

name = throttle
i = 0
total_idle_times[i] = 20344984
time_now() = 122002822
_init_time = 1984664495

ASSERT FAIL
/home/electron/Downloads/gras/lib/gras_impl/input_buffer_queues.hpp:164
total_idle_times[i] <= (time_now() - _init_time)
terminate called after throwing an instance of ‘std::runtime_error’
what(): ASSERT FAIL total_idle_times[i] <= (time_now() - _init_time)

So it seems there is problem with time function

the example i was trying on is :
gnuradio/grc/examples/simple/variable_config.grc
I commented the assert and rebuild the gras and its working fine with
this
example.
But my uhd_fft is showing another error now :

Traceback (most recent call last):
File “/usr/local/bin/uhd_fft”, line 341, in
main ()
File “/usr/local/bin/uhd_fft”, line 337, in main
app = stdgui2.stdapp(app_top_block, “UHD FFT”, nstatus=1)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 38, in init
wx.App.init (self, redirect=False)
File
“/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7978, in init
self._BootstrapApp()
File
“/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7552, in _BootstrapApp
return core.PyApp__BootstrapApp(*args, **kwargs)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 42, in OnInit
self._max_noutput_items)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 64, in init
self.panel = stdpanel (self, self, top_block_maker, max_nouts)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 86, in init
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File “/usr/local/bin/uhd_fft”, line 125, in init
self.scope.set_callback(fftsink_callback)
AttributeError: ‘fft_sink_c’ object has no attribute ‘set_callback’

On 06/11/2013 05:51 PM, Yogesh Dahiya wrote:

app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1)

line 42, in OnInit

I was tracking 3.6.4git but it looks like it was missing some commits to
add the callback to the nongl gui sinks. So I pulled in 3.6.4.2 which
had these commits. Should be good if you update

git pull origin master
git submodule update

-josh

time_now() = 122002822
_init_time = 1984664495

Well thats special, _init_time > time_now…

One possible explanation is that on this version, CLOCK MONOTONIC has a
different monotonic count per thread. given that the tick count is also
pretty small, I suspect this is the case. But not on the more recent
versions of ubuntu. :slight_smile:

I will have to do a little more research. But its safe to comment out
the asserts. The times are just used for the status monitor to determine
the downtime of a particular port.

-josh

On 06/11/2013 07:03 PM, Yogesh Dahiya wrote:

Thanks Its working fine now after the update and commenting assert
statement.

I think I found the problem. The ticks calculation was using 32 bit math
on a 32-bit platform because the type was unsigned long, so there was
numeric overflow. The right casting seems to fix the issue.

-josh

Thanks Its working fine now after the update and commenting assert
statement.