search

jgaeddert / liquid-dsp

digital signal processing library for software-defined radios
http://liquidsdr.org
MIT License
1.87k stars 438 forks source link

Segfault when calling destroy on symsync #18

Closed cwilder23 closed 8 years ago

cwilder23 commented 8 years ago

I am current working the latest build from the master branch.

I recently discovered that a segfault occurs when I call symsync_crcf_destroy from my class destructor. The cause of the segfault is an attempt to free heap memory that was never allocated. I did not investigate the issue in-depth, but briefly looking at the source it looks like it has to do with how the symsync filter module is initializing its IIR filter.

jgaeddert commented 8 years ago

Thanks for pointing this out. I'll take a look at it.

jgaeddert commented 8 years ago

I ran valgrind against the example program and didn't find anything useful. Could you provide a little more information? I understand if not. Here's the command I used and the resulting output file:

$ valgrind --version
  valgrind-3.7.0
$  valgrind --tool=memcheck --leak-check=yes  --show-reachable=yes \
  --num-callers=20 --track-fds=yes  --db-attach=no -v --log-file=valgrind.symsync.txt \
  ./examples/symsync_crcf_example
...
==20592== HEAP SUMMARY:
==20592==     in use at exit: 0 bytes in 0 blocks
==20592==   total heap usage: 149 allocs, 149 frees, 14,124 bytes allocated
==20592== 
==20592== All heap blocks were freed -- no leaks are possible
==20592== 
==20592== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
--20592-- 
--20592-- used_suppression:      4 dl-hack3-cond-1
==20592== 
==20592== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

valgrind.symsync.txt

jgaeddert commented 8 years ago

Same thing with the benchmark program:

$ valgrind --tool=memcheck --leak-check=yes  --show-reachable=yes \
  --num-callers=20 --track-fds=yes  --db-attach=no -v --log-file=valgrind.symsync.txt \
  ./benchmark -q -s symsync
==20830== HEAP SUMMARY:
==20830==     in use at exit: 0 bytes in 0 blocks
==20830==   total heap usage: 300 allocs, 300 frees, 40,912 bytes allocated
==20830== 
==20830== All heap blocks were freed -- no leaks are possible
==20830== 
==20830== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
--20830-- 
--20830-- used_suppression:      4 dl-hack3-cond-1
==20830== 
==20830== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
cwilder23 commented 8 years ago

My apologies in advance if the segfault was something I did. I will write an example this week and see if I can get the segfault to happen again. Unfortunately, I can't share the original project or I would use that code base.

In the meantime, here are the specifics on my build and runtime environment:

BTW. Nice work on the DSP lib. I am teaching myself DSP on embedded systems and it has been a godsend. I have also introduced some of my colleagues to your work.

Thanks,

Chris

On Nov 13, 2015, at 7:59 PM, Joseph D. Gaeddert notifications@github.com wrote:

Same thing with the benchmark program:

$ valgrind --tool=memcheck --leak-check=yes --show-reachable=yes \ --num-callers=20 --track-fds=yes --db-attach=no -v --log-file=valgrind.symsync.txt \ ./benchmark -q -s symsync ==20830== HEAP SUMMARY: ==20830== in use at exit: 0 bytes in 0 blocks ==20830== total heap usage: 300 allocs, 300 frees, 40,912 bytes allocated ==20830== ==20830== All heap blocks were freed -- no leaks are possible ==20830== ==20830== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) --20830-- --20830-- used_suppression: 4 dl-hack3-cond-1 ==20830== ==20830== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) — Reply to this email directly or view it on GitHub.

jgaeddert commented 8 years ago

Chris, First, thanks for the kind words. It's always great to hear when people get good use out of something I've created. Don't worry too much about creating an example that reproduces the segfault. Let me know if you have any other issues, questions, brewing tips, etc. Also, can you let me know what you're project is on? I'm always interested in hearing how people are using liquid!

joseph@liquidsdr.org

cwilder23 commented 8 years ago

Hi Joseph,

Sorry has taken me so long to respond. I had been occupied with the upcoming holiday and work.

I finally got around to re-testing the bug. I the examples that ship with your code and, of course, I had no issues. Definitely on my end. The only difference in my code was that I was using C++ and the filters were declared as class members. The filters were created and initialized in the constructor and destroyed in the destructor. Either way, it appears to be something on my end.

I am using liquid-dsp to reimplement the DSP in the GR-GSM project (https://github.com/ptrkrysik/gr-gsm https://github.com/ptrkrysik/gr-gsm) so that it will run on a Pi2. GR-GSM is implemented using GNURadio and inherently consumes a lot of resources. CPU processing on the Pi2 couldn't keep up with the sample rate needed to decode GSM bursts. Using liquid-dsp and a few other tweaks I was able to synchronize with a live base station and decode GSM burst on the broadcast channel.

Unfortunately, at this time I can’t fully disclose the actual project. When the project is complete it will be made open source. The SDR code will definitely be made available because it is GPL. I will let you know when the project goes public.

Regarding question / comments:

Have you tried to use your PLL filter to stabilize the oscillator in an RTL-SDR? I am using the new RTL-SDR that has a TCOX, but there is still a lot of drift in the target sample rate. If you have used your PLL with the RTL-SDR, did you do any signal recovery (e.g GSM)? I am asking because I was able to use the PLL filter to get the desired constellation from a GSM signal but couldn’t demodulate the signal. It appeared that samples were being cutoff; part of the GSM SCH training sequences were truncated. When I removed the PLL and used just the LPF I was able to demodulate the bursts. I am new to DSP and could be doing something wrong.

Is there a branch of liquid-dsp that uses NEON for computations? If not, do you have plans on using NEON? In case you are not aware, ARM has created framework called Project NE10 (http://projectne10.github.io/Ne10/ http://projectne10.github.io/Ne10/) that make using NEON less painful. If you do end up going down this path I am willing to contribute some time to the effort.

Thanks,

Chris

On Nov 14, 2015, at 8:04 AM, Joseph D. Gaeddert notifications@github.com wrote:

Chris, First, thanks for the kind words. It's always great to hear when people get good use out of something I've created. Don't worry too much about creating an example that reproduces the segfault. Let me know if you have any other issues, questions, brewing tips, etc. Also, can you let me know what you're project is on? I'm always interested in hearing how people are using liquid!

joseph@liquidsdr.org

— Reply to this email directly or view it on GitHub https://github.com/jgaeddert/liquid-dsp/issues/18#issuecomment-156694302.

jgaeddert commented 8 years ago

Chris, sorry for the late response. I've been busy travel lately and I'll try to give you a more detailed response soon.

jgaeddert commented 8 years ago

...and apparently I never got around to responding. Sorry =(

liquid-dsp has some basic neon extensions for certain computations like dot products (https://github.com/jgaeddert/liquid-dsp/blob/master/src/dotprod/src/dotprod_crcf.neon.c). I'll check out project NE10. Thanks for the link!

rustamCoded commented 6 years ago

Hey cwilder3 Were you able to port the gr-gsm from gnuradio to liquid dsp. If yes, can you share the link to if , you had made it opensource.