gr-satellites
gr-satellites copied to clipboard
daniestevez
Segfault on Macbook M1
Hi Folks,
I use miniconda and did a fresh env to get me gr_satellites 4.6 and supporting satellites.
(grsats) chrisbridges@Chriss-MBP Downloads % gr_satellites 47438 --wavfile satnogs_6140184_2022-06-29T09-08-50.wav --samp_rate 48e3
zsh: segmentation fault gr_satellites 47438 --wavfile satnogs_6140184_2022-06-29T09-08-50.wav 48e3
I usually do an .ogg conversion to .wav using satnogs. I checked this in soxi:
(grsats) chrisbridges@Chriss-MBP Downloads % soxi satnogs_6140184_2022-06-29T09-08-50.wav
Input File : 'satnogs_6140184_2022-06-29T09-08-50.wav'
Channels : 1
Sample Rate : 48000
Precision : 16-bit
Duration : 00:10:08.90 = 29227392 samples ~ 45667.8 CDDA sectors
File Size : 58.5M
Bit Rate : 768k
Sample Encoding: 16-bit Signed Integer PCM
Any ideas on this error? 73s C
What version of GNU Radio are you using?
Can you try to produce a backtrace with gdb? You can try running gr-satellites with gdb by doing gdb --args python3 /usr/local/bin/gr_satellites 47438 --wavfile...
By the way, since GNU Radio 3.9 you can read directly OGG files with the --wavfile parameter, but I don't think that would help here.
Ah - good to know about the .ogg files.
(grsats) chrisbridges@Chriss-MBP Downloads % gcc -v
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
And the gdb output:
(grsats) chrisbridges@Chriss-MBP Downloads % gdb --args python3 gr_satellites 47438 --wavfile satnogs_6140184_2022-06-29T09-08-50.wav --samp_rate 48e3
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin13.4.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...
(No debugging symbols found in python3)
(gdb) run
Starting program: /Users/chrisbridges/miniconda3/envs/grsats/bin/python3 gr_satellites 47438 --wavfile satnogs_6140184_2022-06-29T09-08-50.wav --samp_rate 48e3
Unable to find Mach task port for process-id 72260: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
Sorry, I've been travelling and had almost forgotten about this issue.
I don't have a good idea of how to debug this, but something I find strange is the following:
This GDB was configured as "x86_64-apple-darwin13.4.0".
It seems that the GDB you have doesn't match your architecture (it should say arm64).
Another idea: does the segfault happen for all satellites or only for some of them? This may help us isolate the problem to some particular functionality.
I tried with a few others - and I saw the same fault. I did however update and code sign my gdb using:
macos-codesign-gdb.sh
The error is now:
(grsats) chrisbridges@Chriss-MBP Work % gr_satellites 39090 --wavfile ~/Downloads/satnogs_6288421_2022-08-03T05-17-35.ogg
Fatal Python error: take_gil: PyMUTEX_LOCK(gil->mutex) failed
Python runtime state: unknown
This looks a lot like this: https://stackoverflow.com/questions/66026520/fatal-python-error-pymutex-lock-pyruntime-ceval-gil-mutex-failed. And adding: **-Xlinker -undefined -Xlinker dynamic_lookup to the compilation args may fix Mac release issues. Seems like an old error though as results go back to 2014 on this.
My gdb now does this. Running just hangs after creating 2 threads:
(grsats) chrisbridges@Chriss-MBP Work % python --version
Python 3.10.5
(grsats) chrisbridges@Chriss-MBP Work % gdb --args python3 gr_satellites 47438 --wavfile satnogs_6140184_2022-06-29T09-08-50.ogg --samp_rate 48e3
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin13.4.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...
(No debugging symbols found in python3)
(gdb) r
Starting program: /Users/chrisbridges/miniconda3/envs/grsats/bin/python3 gr_satellites 47438 --wavfile satnogs_6140184_2022-06-29T09-08-50.ogg --samp_rate 48e3
[New Thread 0x2a03 of process 18971]
[New Thread 0x2b03 of process 18971]
This looks quite strange. Do simple GNU Radio flowgraphs that don't use gr-satellites work correctly?
The conda builds for gnuradio-satellites pass some CI tests (including on Mac), so rather than the package being completely broken, I'm more inclined to think the cause is some incompatibility between your system and the Mac build system.
This looks like https://github.com/gnuradio/gnuradio/issues/6283, for which a fix is in the works. Once https://github.com/gnuradio/gnuradio/pull/6340 is merged or gets feedback indicating that it will be merged, I plan on updating the conda package to get the fix out as soon as possible.
The conda package has been updated with the fix. Make sure to get gnuradio 3.9.8.0 with build number 6 (ends in "_6") if you still want gr-satellites 4, or 3.10.4.0 build number 7 for gr-satellites 5.
Has anyone given this a try since the fix was merged? I don't have access to an M1 machine to test.
Good poke folks. Was:
(grsats) chrisbridges@Chriss-MBP ~ % conda list | grep -i radio
gnuradio 3.10.3.0 py310he0ef64a_0 conda-forge
gnuradio-satellites 4.6.0 py310h4707503_1 conda-forge
Updated to:
gnuradio 3.10.6.0 py310h561a910_1 conda-forge
gnuradio-satellites 5.2.0 py310h0d93841_2 conda-forge
Output:
(grsats) chrisbridges@Chriss-MBP ~ % gr_satellites FUNcube-1 --wavfile ./Downloads/satnogs_7400664_2023-04-11T14-53-43.ogg --samp_rate 48e3
pagesize :debug: Setting pagesize to 4096 B
top_block_impl :debug: Using default scheduler "TPB"
Will now test for the specific versions above.
The following packages will be DOWNGRADED:
gnuradio 3.10.6.0-py310h561a910_1 --> 3.10.4.0-py310h653ce72_8
...
gnuradio-satellit~ 5.2.0-py310h0d93841_2 --> 5.1.1-py310h8f97ed4_0
The same command above did nothing. Zero output.
Edit: gdb run starts two threads and hangs, cannot get a traceback either.
Hi Chris, can you test with this WAV file just in case there is something wrong with the SatNOGS one?
I've managed to decode 130 packets in the OGG file you use with
gr_satellites FUNcube-1 --wavfile satnogs_7400664_2023-04-11T14-53-43.ogg --f_offset 12500
Apparently SatNOGS now records even narrowband signals using an IF of 12 kHz, while gr-satellites assumes 1.5 kHz for a narrowband signal (i.e., if it fits in 3 kHz bandwidth). Using --f_offset 12000 also works.
In any case, when you run gr_satellites with this recording, does it finish? If not, does it keep having high CPU usage forever, or does it hang without any CPU usage?
Bah. It all works now.
----------------------------------------
Fitter Message 6
----------------------------------------
b"Congrats to Year 4 at at St Peter's school in Thanet from FUNcube-1 in Space\x00\...\x00"
My versions are: gnuradio 3.10.4.0 py310h653ce72_8 conda-forge gnuradio-satellites 5.1.1 py310h8f97ed4_0 conda-forge
Some sort of 'ldconfig' issue maybe as I did do a restart of the Macbook. PEBCAK also likely. Feel free to close!
Feel free to close.