Valgrind & gr_fir_fff_simd::set_taps - memory leak

I am trying to track down an insidious little memory leak in a Block
that
wraps the DSD vocoder. I have run Valgrind against it and didn’t find
anything obvious. Valgrind didn’t like the way memory was being assigned
by
set_taps and it seems like this came up in a previous thread too:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-06/msg00015.html

It doesn’t look like there was a definitive answer if this was a real
problem or just Valgrind getting confused.

For Background:
I am running GNURadio 3.6.5.1 and my program is all in C++ without any
python. The DSD Vocoder block run the DSD program (which is a C program)
in
a pthread and passes it samples using a shared array and some mutex. For
each separate talkgroup conversation on a trunking radio system, the
TopBlock gets locked, a new logging flow with the DSD block in it gets
created and then connected. When the conversation is over the tb get
locked/unlocked and the flows is destroyed. Are there any obvious
gotchas
that might leak with this approach? I am using detached threads to run
DSDand deleting all of the
mutex/cond I init.

Here is the Valgrind output concerning the set_taps:

Decoding only P25 Phase 1 frames.
Enabling only C4FM modulation optimizations.
Recv [ 0 ] Tg: 1616 Freq: 856.6
==5138== Thread 9:
==5138== Invalid read of size 8
==5138== at 0x4F3F48C: float_dotprod_sse (in
/usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F40770: gr_fir_fff_generic::filterN(float*, float
const*,
unsigned long) (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F41D02: gr_fir_filter_fff::work(int, std::vector<void
const*, std::allocator<void const*> >&, std::vector<void*,
std::allocator<void*> >&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F29EF3: gr_sync_decimator::general_work(int,
std::vector<int, std::allocator >&, std::vector<void const*,
std::allocator<void const*> >&, std::vector<void*, std::allocator<void*>

&) (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F099D5: gr_block_executor::run_one_iteration() (in
/usr
/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F33B32: gr_tpb_thread_body::gr_tpb
_thread_body(boost::shared_ptr<gr_block>, int) (in /usr/local/lib/
libgnuradio-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F27077:
boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<
tpb_container>, void>::invoke(boost::detail::function::function_buffer&)
(in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138== by 0x581F14E:
boost::detail::thread_data<boost::function0
::run() (in /usr/local/lib/libgruel-3.6.5.1.so.0.0.0)
==5138== by 0x76716E8: ??? (in /usr/lib/libboost_thread.so.1.49.0)
==5138== by 0x5A39F8D: start_thread (pthread_create.c:311)
==5138== by 0x7394E1C: clone (clone.S:113)
==5138== Address 0xfc63288 is 88 bytes inside a block of size 95
alloc’d
==5138== at 0x4C2CD7B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck
-amd64-linux.so)
==5138== by 0x4F79FBE: malloc16Align (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F7A009: calloc16Align (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F3D435: gr_fir_fff_simd::set_taps(std::vector<float,
std::allocator > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F3D553:
gr_fir_fff_simd::gr_fir_fff_simd(std::vector<float,
std::allocator > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F3D7F8:
gr_fir_fff_sse::gr_fir_fff_sse(std::vector<float,
std::allocator > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F3BAE0:
gr_fir_sysconfig_x86::create_gr_fir_fff(std::vector<float,
std::allocator > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F41FF5: gr_fir_filter_fff::gr_fir_filter_fff(int,
std::vector<float, std::allocator > const&) (in /usr/local/lib/
libgnuradio-core-3.6.5.1.so.0.0.0)
==5138== by 0x4F4217B: gr_make_fir_filter_fff(int, std::vector<float,
std::allocator > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138== by 0x482D55: log_dsd::log_dsd(float, float, long, int)
(logging_receiver_dsd.cc:76)
==5138== by 0x482531: make_log_dsd(float, float, long, int)
(logging_receiver_dsd.cc:8)
==5138== by 0x46116F: main (smartnet.cc:394)

And here is the code that creates the fir_filter_fff (in the
constructorfor the logger):

const float a[] = { 0.1, 0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1};
std::vector data( a,a + sizeof( a ) / sizeof( a[0] ) );
sym_filter = gr_make_fir_filter_fff(1, data);

On 10/21/2013 01:43 PM, Luke B. wrote:

I am trying to track down an insidious little memory leak in a Block that
wraps the DSD vocoder. I have run Valgrind against it and didn’t find
anything obvious. Valgrind didn’t like the way memory was being assigned by
set_taps and it seems like this came up in a previous thread too:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-06/msg00015.html

Look at https://scan.coverity.com/ . You’ll need to make an account and
we’ll need to grant you access. It is scanning the 3.7 code, but you
might be able to gain some insight by looking at the static analysis.

Philip

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs