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.

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

grgsm_scanner Aborted (core dumped) #336

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

Comments

Projects
None yet
7 participants
@toombr

toombr commented Sep 17, 2017

grgsm_scanner

Aborted (core dumped)
What is the problem&

@loonydev

This comment has been minimized.

Show comment
Hide comment
@loonydev

loonydev Sep 18, 2017

Try
sudo sysctl kernel.shmmni=32000

loonydev commented Sep 18, 2017

Try
sudo sysctl kernel.shmmni=32000

@petterreinholdtsen

This comment has been minimized.

Show comment
Hide comment
@petterreinholdtsen

petterreinholdtsen Sep 18, 2017

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. :(

Contributor

petterreinholdtsen commented Sep 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@velichkov

velichkov Sep 20, 2017

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

Contributor

velichkov commented Sep 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@petterreinholdtsen

petterreinholdtsen Sep 20, 2017

Contributor
Contributor

petterreinholdtsen commented Sep 20, 2017

@velichkov

This comment has been minimized.

Show comment
Hide comment
@velichkov

velichkov Sep 20, 2017

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

Contributor

velichkov commented Sep 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@petterreinholdtsen

petterreinholdtsen Sep 20, 2017

Contributor
Contributor

petterreinholdtsen commented Sep 20, 2017

@velichkov

This comment has been minimized.

Show comment
Hide comment
@velichkov

velichkov Sep 20, 2017

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

Contributor

velichkov commented Sep 20, 2017

(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

This comment has been minimized.

Show comment
Hide comment
@petterreinholdtsen

petterreinholdtsen Sep 20, 2017

Contributor
Contributor

petterreinholdtsen commented Sep 20, 2017

@velichkov

This comment has been minimized.

Show comment
Hide comment
@velichkov

velichkov Sep 20, 2017

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
Contributor

velichkov commented Sep 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@petterreinholdtsen

petterreinholdtsen Sep 20, 2017

Contributor
Contributor

petterreinholdtsen commented Sep 20, 2017

@velichkov

This comment has been minimized.

Show comment
Hide comment
@velichkov

velichkov Sep 21, 2017

Contributor

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

Contributor

velichkov commented Sep 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@petterreinholdtsen

petterreinholdtsen Sep 21, 2017

Contributor
Contributor

petterreinholdtsen commented Sep 21, 2017

@petterreinholdtsen

This comment has been minimized.

Show comment
Hide comment
@petterreinholdtsen

petterreinholdtsen Sep 28, 2017

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?

Contributor

petterreinholdtsen commented Sep 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@petterreinholdtsen

petterreinholdtsen Oct 10, 2017

Contributor

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

Contributor

petterreinholdtsen commented Oct 10, 2017

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

@pbraun9

This comment has been minimized.

Show comment
Hide comment
@pbraun9

pbraun9 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.

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.

@mazen-bassiouny

This comment has been minimized.

Show comment
Hide comment
@mazen-bassiouny

mazen-bassiouny May 20, 2018

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 !

mazen-bassiouny commented May 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@velichkov

velichkov May 20, 2018

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: mossmann/hackrf@b4a452c and
https://github.com/mossmann/hackrf/releases/tag/v2017.02.1

Contributor

velichkov commented May 20, 2018

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: mossmann/hackrf@b4a452c and
https://github.com/mossmann/hackrf/releases/tag/v2017.02.1

@mazen-bassiouny

This comment has been minimized.

Show comment
Hide comment
@mazen-bassiouny

mazen-bassiouny May 21, 2018

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

mazen-bassiouny commented May 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@velichkov

velichkov May 21, 2018

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

Contributor

velichkov commented May 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@mazen-bassiouny

mazen-bassiouny May 21, 2018

It worked with me ,, thanks alot

mazen-bassiouny commented May 21, 2018

It worked with me ,, thanks alot

@ptrkrysik

This comment has been minimized.

Show comment
Hide comment
@ptrkrysik

ptrkrysik Jun 2, 2018

Owner

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

Owner

ptrkrysik commented Jun 2, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment