Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

grgsm_scanner Aborted (core dumped) #336

Closed
toombr opened this issue Sep 17, 2017 · 21 comments
Closed

grgsm_scanner Aborted (core dumped) #336

toombr opened this issue Sep 17, 2017 · 21 comments

Comments

@toombr
Copy link

toombr commented Sep 17, 2017

grgsm_scanner

Aborted (core dumped)
What is the problem&
@loonydev
Copy link
Contributor

Try
sudo sysctl kernel.shmmni=32000

@petterreinholdtsen
Copy link
Contributor

I experience the crash too, when using it with a HackrF One. I get a segfault. To see more about what is going wrong, I patched the latest git version like this:

--- /usr/bin/grgsm_scanner      2017-09-18 11:14:10.000000000 +0200
+++ /tmp/grgsm_scanner  2017-09-18 13:10:12.567799968 +0200
@@ -313,12 +313,12 @@
 
             # silence rtl_sdr output:
             # open 2 fds
-            null_fds = [os.open(os.devnull, os.O_RDWR) for x in xrange(2)]
+            #null_fds = [os.open(os.devnull, os.O_RDWR) for x in xrange(2)]
             # save the current file descriptors to a tuple
-            save = os.dup(1), os.dup(2)
+            #save = os.dup(1), os.dup(2)
             # put /dev/null fds on 1 and 2
-            os.dup2(null_fds[0], 1)
-            os.dup2(null_fds[1], 2)
+            #os.dup2(null_fds[0], 1)
+            #os.dup2(null_fds[1], 2)
 
             # instantiate scanner and processor
             scanner = wideband_scanner(rec_len=6 - speed,
@@ -360,11 +360,11 @@
             scanner = None
 
             # restore file descriptors so we can print the results
-            os.dup2(save[0], 1)
-            os.dup2(save[1], 2)
+            #os.dup2(save[0], 1)
+            #os.dup2(save[1], 2)
             # close the temporary fds
-            os.close(null_fds[0])
-            os.close(null_fds[1])
+            #os.close(null_fds[0])
+            #os.close(null_fds[1])
             if prn:
                 prn(found_list)
             signallist.extend(found_list)

After this patching I get this error:

% /tmp/grgsm_scanner 
linux; GNU C++ version 6.3.0 20170221; Boost_106200; UHD_003.009.005-0-unknown


Args= 
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya 
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
Number of USB devices: 9
USB device 1d50:6089: 000000000000000014d463dc2f282be1 match
Using HackRF One with firmware 2017.02.1 
set_min_output_buffer on block 2 to 4000000
set_min_output_buffer on block 4 to 4000000
set_min_output_buffer on block 3 to 4000000
Segmentation fault
%

I tried the 'sysctl kernel.shmmni=32000' proposal, but it had no effect. Running in valgrind, the code crash like this in the scanner.start() call:

==491== Use of uninitialised value of size 8
==491==    at 0x1E0DB6EC: ??? (in /usr/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so.0.1.4)
==491==    by 0x75BB766: gr::sync_block::general_work(int, std::vector<int, std::allocator<int> >&, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x75707EF: gr::block_executor::run_one_iteration() (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x75C785B: gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr::block>, int) (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x75B8324: ??? (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x75548B1: ??? (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x8BB2115: ??? (in /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.62.0)
==491==    by 0x4E3F493: start_thread (pthread_create.c:333)
==491== 
OOOOOOOOOOOOOOOOOOOOOOOOOOOOO==491== 
==491== Process terminating with default action of signal 11 (SIGSEGV)
==491==  Bad permissions for mapped region at address 0x30219000
==491==    at 0x1E0DB6F1: ??? (in /usr/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so.0.1.4)
==491==    by 0x75BB766: gr::sync_block::general_work(int, std::vector<int, std::allocator<int> >&, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x75707EF: gr::block_executor::run_one_iteration() (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x75C785B: gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr::block>, int) (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x75B8324: ??? (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x75548B1: ??? (in /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.10)
==491==    by 0x8BB2115: ??? (in /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.62.0)
==491==    by 0x4E3F493: start_thread (pthread_create.c:333)
==491== 
==491== HEAP SUMMARY:
==491==     in use at exit: 27,327,702 bytes in 36,071 blocks
==491==   total heap usage: 146,482 allocs, 110,411 frees, 98,327,241 bytes allocated
==491== 
==491== LEAK SUMMARY:
==491==    definitely lost: 786,736 bytes in 8 blocks
==491==    indirectly lost: 0 bytes in 0 blocks
==491==      possibly lost: 1,356,445 bytes in 1,634 blocks
==491==    still reachable: 25,184,521 bytes in 34,429 blocks
==491==         suppressed: 0 bytes in 0 blocks
==491== Rerun with --leak-check=full to see details of leaked memory
==491== 
==491== For counts of detected and suppressed errors, rerun with: -v
==491== Use --track-origins=yes to see where uninitialised values come from
==491== ERROR SUMMARY: 6769840 errors from 110 contexts (suppressed: 0 from 0)
Killed

I have no idea how to get any further. :(

@velichkov
Copy link
Contributor

Hi @petterreinholdtsen,

==491== Use of uninitialised value of size 8
==491== at 0x1E0DB6EC: ??? (in /usr/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so.0.1.4)

==491== Process terminating with default action of signal 11 (SIGSEGV)
==491== Bad permissions for mapped region at address 0x30219000
==491== at 0x1E0DB6F1: ??? (in /usr/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so.0.1.4)

At first glance the problem seems to be in the gr-osmosdr library, you could try to report this problem to them as well.

You could also try to install the debug info packages for gr-osmosdr and then run the grgsm_scanner under gdb and when it crashes take a backtrace

@petterreinholdtsen
Copy link
Contributor

petterreinholdtsen commented Sep 20, 2017 via email

@velichkov
Copy link
Contributor

Note, this only happen with hackrf, not with the RTL2838.

I don't have hackrf so I can't reproduce this.
Could you check whether the /usr/bin/osmocom_fft and /usr/bin/osmocom_spectrum_sense are working with hackrf

==26239== at 0x1E2766E8: hackrf_source_c::work(int, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) (hackrf_source_c.cc:380)
==26239== Bad permissions for mapped region at address 0x220C9000

From lib/hackrf/hackrf_source_c.cc

379     for (int i = 0; i < remaining; ++i)
380       *out++ = _lut[ *(buf + i) ];

It would be useful to run it through gdb and check if the two pointers are valid and which one points to mapped region at address 0x220C9000

(gdb) p out
(gdb) p *out
(gdb) p buf
(gdb) p *(buf + i)

and what the value of i and remaining is when it crashed

(gdb) p i
(gdb) p remaining

And again consider reporting this to the gr-osmosdr mailing list https://lists.osmocom.org/mailman/listinfo/osmocom-sdr

@petterreinholdtsen
Copy link
Contributor

petterreinholdtsen commented Sep 20, 2017 via email

@velichkov
Copy link
Contributor

(gdb) p *(buf+i)
Cannot access memory at address 0x555557191000
(gdb) p i
$4 = 2446880

Now either buf pointer is not valid or i is too big

In your first valgrind output there was this error ==491== Use of uninitialised value of size 8 and most probably this is when the pointer or i gets invalid value. Could you run it again with valgrind and provide the first error, now after debug info symbols are installed the error should be more verbose

@petterreinholdtsen
Copy link
Contributor

petterreinholdtsen commented Sep 20, 2017 via email

@velichkov
Copy link
Contributor

Note, it is not the first error, it is the second to last error. Here is the tail of the valgrind run, with a bit more included than last time:

Could you upload the full log somewhere - pastbin, dropbox, google drive ... and provide the link

Also under gdb after it crashes execute

(gdb) set print pretty on
(gdb) info locals
(gdb) info args
(gdb) p *buf
(gdb) p *this

@petterreinholdtsen
Copy link
Contributor

petterreinholdtsen commented Sep 20, 2017 via email

@velichkov
Copy link
Contributor

velichkov commented Sep 21, 2017 •
edited
Loading

noutput_items = 2000127
_samp_avail = -1 737 984,
remaining = 3738111
_buf_len = 262144,

Something is wrong with the buffer management, the _samp_avail has become negative, initially it it set to _samp_avail = _buf_len / BYTES_PER_SAMPLE; which is 131072

229       _buf[i] = (unsigned short *) malloc(_buf_len);

375     buf = _buf[_buf_head];
376 
377     int remaining = noutput_items - _samp_avail;
378 
379     for (int i = 0; i < remaining; ++i)
380       *out++ = _lut[ *(buf + i) ];
381 
382     _buf_offset = remaining;
383     _samp_avail = (_buf_len / BYTES_PER_SAMPLE) - remaining;

then on the first run the remaining should be 2000127 - 131072 = 1869055 and the for loop will read way past the buffer end. I really don't understand how this code is supposed to work and not having hacrf makes debugging it really hard.

Try to run grgsm_scanner with smaller sample rate -s 0.8e6 or -s 0x1.2e6 and osmocom_fft with the default grgsm_scanner sample rate -s 2e6

@petterreinholdtsen
Copy link
Contributor

petterreinholdtsen commented Sep 21, 2017 via email

@petterreinholdtsen
Copy link
Contributor

Piotr was able to debug the hackrf crash, and discovered that this patch avoided the segfault:

diff --git a/apps/grgsm_scanner b/apps/grgsm_scanner
index 1bff63a..c816814 100755
--- a/apps/grgsm_scanner
+++ b/apps/grgsm_scanner
@@ -209,7 +209,6 @@ class wideband_scanner(gr.top_block):
         # if no file name is given process data from rtl_sdr source
         print "Args=", args
         self.rtlsdr_source = osmosdr.source(args="numchan=" + str(1) + " " + args)
-        self.rtlsdr_source.set_min_output_buffer(int(sample_rate*rec_len))
         self.rtlsdr_source.set_sample_rate(sample_rate)
 
         # capture half of GSM channel lower than channel center (-0.1MHz)

I'm not sure why, but perhaps it solve your problem too?

@petterreinholdtsen
Copy link
Contributor

Hi. Any hope to have a new gr-gsm release soon with this fixed included?

@velichkov velichkov mentioned this issue Jan 10, 2018
Closed
@pbraun9
Copy link

pbraun9 commented Apr 15, 2018

This one-line patch also avoids the segfault here, on Debian systems against HackRF host code git-b4a452c and 2017.02.1.

@velichkov velichkov mentioned this issue May 1, 2018
Open
@velichkov velichkov mentioned this issue May 19, 2018
Closed
@mazen-bassiouny
Copy link

mazen-bassiouny commented May 20, 2018 •
edited
Loading

i am sorry but i do not understand ? where is the patch ? how can i execute it ?what does that mean (ode git-b4a452c and 2017.02.1.) these line of code are already there in my code !

@velichkov
Copy link
Contributor

Hi @mazen-bassiouny,

where is the patch ?

It's part of the comment #336 (comment)

how can i execute it ?

https://unix.stackexchange.com/questions/232879/applying-a-diff-patch
https://www.thegeekstuff.com/2014/12/patch-command-examples/

what does that mean (ode git-b4a452c and 2017.02.1.)

Two versions of hackrf he has tested with: greatscottgadgets/hackrf@b4a452c and
https://github.com/mossmann/hackrf/releases/tag/v2017.02.1

@mazen-bassiouny
Copy link

mazen-bassiouny commented May 21, 2018 •
edited
Loading

so this patch just to comment this line ?:
(self.rtlsdr_source.set_min_output_buffer(int(sample_rate*rec_len))
as i did before but the segfault still exists.
Is there any other action after commenting the line that i can do ? how can i rebuild again if i installed with PyBOMBS

@velichkov
Copy link
Contributor

so this patch just to comment this line ?:
(self.rtlsdr_source.set_min_output_buffer(int(sample_rate*rec_len))

Correct.

as i did before but the segfault still exists.
Is there any other action after commenting the line that i can do ?

After applying the patch you need to install the modified version, run make install

how can i rebuild again if i installed with PyBOMBS

Try pybombs rebuild gr-gsm. See also pybombs --help

@mazen-bassiouny
Copy link

It worked with me ,, thanks alot

@ptrkrysik
Copy link
Owner

I just commented out that line so hackrf shouldn't crash.

@velichkov velichkov mentioned this issue Sep 5, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@petterreinholdtsen @velichkov @ptrkrysik @loonydev @pbraun9 @toombr @mazen-bassiouny