[Discuss-gnuradio] vector sink "malloc(): memory corruption" / object was probably modified after being freed

2018-04-15 Thread Brad Hein
The Vector Sink is coming in very handy for some experimentation I'm doing.
I'm analyzing the output of an FFT block which terminates into a float
vector sink. every few seconds from a thread which then calls reset() to
clear the contents in preparation for another read. This seems problematic
as the program crashes quite frequently after seconds to minutes of
operation. Based on my layman's perspective it seems to be a memory leak in
the vector block.

I tried many things over the last couple of days. Nothing seems to mitigate
it. For example self.lock and self.unlock to lock the flowgraph before
reading from the vector (results in flowgraph never starting back up, seems
to be a whole different issue)... I tried using python copy.deepcopy to
make a copy of the vector contents before using it but that didn't help
eiehter.

When the exception occurs, it seems to happen right after resetting the
vector sink.

My flowgraph doesn't run standalone and requires a number of other
applications to function but I'll work on getting it up to github for
review if that helps

Gnuradio 3.7.11.1 on a CentOS VM (Linux 3.10.0-514.el7.x86_64 #1 SMP Tue
Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux)

BTW when the exception occurs on OSX the error is:

Python(86100,0x7eab9000) malloc: *** error for object 0x7f94bf9042b8:
incorrect checksum for freed object - object was probably modified after
being freed.


Stack Trace samples from Linux (they are all quite similar to eachother
with only slight differences in the  addresses):


*** Error in `python': malloc(): memory corruption: 0x7fa0cc019ba0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x7dd4d)[0x7fa14f448d4d]
/lib64/libc.so.6(__libc_malloc+0x4c)[0x7fa14f44afbc]
/lib64/libstdc++.so.6(_Znwm+0x1d)[0x7fa145c0e0cd]
/usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(_ZNSt6vectorIfSaIfEEaSERKS1_+0xd4)[0x7fa13df58e64]
/usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(+0x12c8a0)[0x7fa13deea8a0]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6df0)[0x7fa150195af0]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d]
/lib64/libpython2.7.so.1.0(+0x7088d)[0x7fa15012188d]
/lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x17fd)[0x7fa1501904fd]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d]
/lib64/libpython2.7.so.1.0(+0x70798)[0x7fa150121798]
/lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
/lib64/libpython2.7.so.1.0(+0x5a8d5)[0x7fa15010b8d5]
/lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
/lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7fa15018e6f7]
/lib64/libpython2.7.so.1.0(+0x1155c2)[0x7fa1501c65c2]
/lib64/libpthread.so.0(+0x7dc5)[0x7fa14fe9cdc5]
/lib64/libc.so.6(clone+0x6d)[0x7fa14f4c276d]
=== Memory map: 
0040-00401000 r-xp  fd:00 242126
/usr/bin/python2.7
0060-00601000 r--p  fd:00 242126
/usr/bin/python2.7
--
*** Error in `python': malloc(): memory corruption: 0x7f03ac00f640 ***
=== Backtrace: =
/lib64/libc.so.6(+0x7dd4d)[0x7f04382b6d4d]
/lib64/libc.so.6(__libc_malloc+0x4c)[0x7f04382b8fbc]
/lib64/libstdc++.so.6(_Znwm+0x1d)[0x7f042ea7c0cd]
/usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(_ZNSt6vectorIfSaIfEEaSERKS1_+0xd4)[0x7f0426dc6e64]
/usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(+0x12c8a0)[0x7f0426d588a0]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6df0)[0x7f0439003af0]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd]
/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7f0439005e3d]
/lib64/libpython2.7.so.1.0(+0x7088d)[0x7f0438f8f88d]
/lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f0438f6a8e3]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x17fd)[0x7f0438ffe4fd]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd]
/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd]
/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7f0439005e3d]
/lib64/libpython2.7.so.1.0(+0x70798)[0x7f0438f8f798]
/lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f0438f6a8e3]
/lib64/libpython2.7.so.1.0(+0x5a8d5)[0x7f0438f798d5]
/lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f0438f6a8e3]
/lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7f0438ffc6f7]
/lib64/libpython2.7.so.1.0(+0x1155c2)[0x7f04390345c2]
/lib64/libpthread.so.0(+0x7dc5)[0x7f0438d0adc5]
/lib64/libc.so.6(clone+0x6d)[0x7f043833076d]
=== Memory map: 
0040-00401000 r-xp  fd:00 242126

[Discuss-gnuradio] Synchronizing to an external data stream ?

2018-04-15 Thread Carlo Manfredini
Hi all, newbie question.I have experience with hardware approaches but am
fairly new to SDR and am keen to get into its massive capabilities.

I have an external 2.1 kbps bipolar digital data stream I wish to sample
into GR via an audio sampling device (audio source) which samples at 48k.
That part is fine.

However I need to be able to align my sampling with the incoming stream so
that I can convert the bits into symbols for some IQ modulation work I wish
to do.

The data rate and the audio sampling rate are independent of each other and
obviously of different rates.

My thoughts are that I need to do data rate clock recovery (to extract the
2.1 kbps clock) so that I can align and convert the samples into bits for
the further modulation processing etc.

I have unsuccessfully tried fractional sampling, polyphase clock sync,
clock recovery MM & costas loop in various ways. My lack of success is most
likely due to my not being sure of which approach to pursue.

Can someone suggest an approach which is most likely to succeed so that I
can focus on that until I get a correct result.

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