SoapySDRServer segfault #26
Comments
|
I must have missed this bug. It looks like the SDR Play disconnected or crashed for some reason. I dont think there is anything to fix on the Soapy side of things |
|
Getting this issue with fresh pull, have pulled/built current versions of SoapySDR SoapySDRPlay and SoapyRemote, no build errors encountered. Soapy remote loads fine, then attempt to connect with CubicSDR remotely from Local LAN: `/opt/SoapySDR/build# SoapySDRServer --bind="0.0.0.0:1234" Soapy Server -- Use any Soapy SDR remotely###################################################### SoapyServerListener::accept(192.168.1.8:46996) |
|
Hmm... Can you run SoapySDRServer in gdb? Possibly build with -DCMAKE_BUILD_TYPE=Debug as well. I think a traceback here will be helpful. Basically we need to know where is crashing and that the input may have been so we can narrow it down. |
|
Hi, Running on raspberry pi 3 with SDRplay as receiver and cubicSDR on Mac. (gdb) run Soapy Server -- Use any Soapy SDR remotely###################################################### c4288117-626f-150a-8567-19aa007f0101 Thread 39 "SoapySDRServer" received signal SIGSEGV, Segmentation fault. |
|
Any backtrace? can you run |
|
[New Thread 0x71a4f050 (LWP 803)] Thread 27 "SoapySDRServer" received signal SIGSEGV, Segmentation fault. (gdb) bt |
|
Let me add, the refresh from cubicSDR works fine, the SoapyServer is detected and the SDRplay is identified. SoapyServer crashes as soon as I connect to it. |
|
I cant tell anything form the backtrace. You probably have to build SoapySDRPlay with some prints and just see where it dies, which function or which mir_sdr call is bombing out, I dont know where that might lead... If its just dying in connect before any settings are applied, it could be here: If you happen to know which call or function on the PC side causes the crash, I can point you to a more specific place. |
|
Do you have a version with debug prints I could use and recompile it? |
|
I am experiencing the same segfaults on both the Pi running SoapyServer, but only when the Pi is connected by Wifi to a Win10 or MacOS CubicSDR running as client. When the connection is via a wired Ethernet everything runs fine. On the Pi, gdb bt shows that I segfault in memcmp() but the stack is hosed so I can't tell what function is calling memcmp(). I have added a number of std::cerr printouts to SoapyServerThreadData::handlerLoop() which haven't given me any more insight. I'm a C programmer, not C++, so I'm a little lost as to how to debug further, but it seems that in the context of a Wifi connection there is some unhandled error condition in Soapy code common to the client and server. |
|
@rrobinett This is where all of the calls get handled: https://github.com/pothosware/SoapyRemote/blob/master/server/ClientHandler.cpp#L86 and this is what gets called inside the handler loop. You can basically see that its getting a enum value "call" and based on that value making the function call into the underlying module. If you can print the value of call (its just an integer), we can figure out which call is actually the one dying and dive deeper and make sure that the stack is really getting into that call and not leaving/segfaulting. Or we find out that the crash is somehow before that and its a socket issue of some kind... Either way, a dump of the call IDs would essentially give a trace of where the client called in and where it last was before something crashed. Hope that helps, I'm happy to hear where its dying, feel free to post any outputs, etc from this |
|
I added this printout: bool SoapyClientHandler::handleOnce(SoapyRPCUnpacker &unpacker, SoapyRPCPacker &packer) .... And got this logged output which suggests it fails in handling case 708 == SOAPY_REMOTE_GET_GAIN_RANGE_ELEMENT [New Thread 0x70f3c050 (LWP 5364)] Program received signal SIGSEGV, Segmentation fault. |
|
I spoke too soon. After adding another printout in case 708, another run terminated after a different case: SoapyClientHandler::hendleOnce() call =#700 Program received signal SIGSEGV, Segmentation fault. And removing the case printout results in the crash moving to after case 1401. |
|
I have discovered that the segfault is associated with higher bitrates. When I turn the sample rate down to 1 Mbps or less the system starts running stably. |
|
Not sure what to make of the crash log other than that, maybe we are changing settings while streaming, not sure if thats an issue for the SDRPlay drivers. If thats the case, we can sprinkle As far as the high traffic, there's some command line utilities that can simulate the traffic: Would be interesting to see if its the traffic since this really doesnt touch settings or multi-threadedness like cubicsdr.
Of course thats the problem with segfaults :-) But hopefully its something that can be protected against when its pinned down. |
|
@guruofquality @rrobinett FYI in CubicSDR settings are only written in the unique thread |
|
@vsonnier Well, the read settings calls are basically just simple variable reads, so Im not worried about them anyway. But, SoapyRemote client purposely allows for settings and streams to be accessed on separate threads. So even if SoapySDRPlay is accessed sequentially from cubicsdr, the settings and streaming are getting multi-threaded simply because SoapyRemoteServer spawns its own forwarding threads for the streams that are separate from the client settings handling. So I don't know if this is the problem, but it was intended for settings and streams to be called from different threads, so if SoapySDRPlay's miri API cant handle being accessed simultaneously in different thread contexts, we will need some more of those mutex calls in the settings calls. @rrobinett It would be interesting to know from the output if the handler completed or bombed out, I would add a print like so in addition to the call code you already have. Also, now that we brought it up, there is a second thread to be concerned about: https://github.com/pothosware/SoapyRemote/blob/master/server/ServerStreamData.cpp#L137 One of these two threads has to be dying. And once we know which one we can dig into the SoapySDRPlay functions. Although experimenting with some additional mutex calls might be worthwhile as well given the discussion. |
|
@rrobinett @guruofquality On the SoapySDRPlay repo, I've pushed an experimental branch: https://github.com/pothosware/SoapySDRPlay/tree/vso_protected_api_calls that tries to protect against concurrent access the internal state of the module. |
|
I am very much a newbie here and have other projects preempting my time on this and am pretty unfamiliar with these development environments, so I will be a pretty inefficient diagnostician. But here is my results this evening: @guruofquality I added your four printf lines and of course got a lot of output, but the system ran fine a 250K sps. When I change the sps rate on Cubic from 1 Mbps to 2 Mbps I got an immediate segfault on both the SoapyServer and Cubic. Here are the last few lines of the Server output: readStream with numelems = 332 @vsonnier I downloaded your patch and it seems to contain cpp and hpp files which would replace those in the ...Master/client/ directory. They compile on the Pi but of course I don't run the client on the Pi. Unfortunately I have so far only learned how to recompile and debug the SoapyServer on the Pi. I have been using Win10 as my CubicSDR platform where I have no development environment and also no familiarity with Windows developing. I am willing to debug Cubic and it would seem that doing so on Win10 would be most productive, but I'll need a tutorial on setting up the IDE |
|
@rrobinett Sorry you are wrong, my branch is for a alternate version of the SoapySDRplay module, and do not touch SoapyRemote code at all. The Server will then make use on this new SoapySDRplay module on the Pi to communicate with the device. So you have to compile the SoapyRemote (what you did until then) and this SoapySDRplay module separately. Once again Kevin Loughin (@loughkb) scripts are a good inspiration for that. We can safely assume the Mirics API and driver are already installed on you Pi, so which remains is git clone https://github.com/pothosware/SoapySDRPlay.git
cd SoapySDRPlay
git checkout -b vso_protected_api_calls origin/vso_protected_api_calls
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug
make
make install |
|
The 'make install' fails: pi@raspberrypi:~ $ git clone https://github.com/pothosware/SoapySDRPlay.git Makefile:104: recipe for target 'install' failed |
|
looks like a permissions issue, use... sudo make install |
|
I spoke too soon. 'sudo make install' was successful and there is now a lot more debug output before the segfault: pi@raspberrypi:~ $ SoapySDRServer --bind >& soapy.log |
|
FYI @rrobinett I updated the branch https://github.com/pothosware/SoapySDRPlay/tree/vso_protected_api_calls to fix a performance regression seen in CubicSDR, although it should change nothing on the present issue. |
|
@vsonnier Something else im not sure about. Obviously the setup/activate stream and anything that talks to the mirics api needs the |
|
@guruofquality Well, in my latest version I think the If we start to be super-clean here by adding a As for the other modules indeed none of them have proper concurrent-access protection against their internal state, or even against their own callback threads vs. their internal state either. Are we even sure it is a multithreaded problem at all ? My previous commits seem to have little effect on @rrobinett troubles though. (which, in a multithreaded Hell is no proof of existence or even the contrary, I know) |
|
I dont want to get carried away with the threading stuff. It looks like by merit of the implementation, readStream is safe to use from another thread anyway. So we were basically doing the right thing. Does cubicsdr operate on floats? Because soapyremote will use complex shorts to save bandwidth, so if complex shorts have a bug for SoapySDRPlay, its another reason we would not see it normally. If possible, we can check this by forcing floats over the network with the remote:format stream arg (if cubic can pass this somehow?) https://github.com/pothosware/SoapyRemote/wiki#remote-format rrobinett did show a crash going into readStream and not coming out: So thats just a hunch but I would try to see how far the prints can get into SoapySDRPlay::readStream(), by sprinkling a few Also this probably isnt an issue, but shortsPerWord is not set in the setupStream. I checked that it was initialized, but if the stream was setup once to floats and then again to shorts, it could be set wrong (for whatever thats worth). |
I've seen that and changed it already in previous commits of the test branch :) CubicSDR indeed operates on CF32, but we can set any allowed format on SoapyRemote. Blocking here means At the same time, on the server side: Of course, no crash seen. |
|
needs to go immediately before StreamInit and ideally to be tested :-) |
|
sorry, I meant compile time, not runtime! too many things going on at once! |
|
We need a chat :) |
|
Done, commited on SoapySDRplay master. |
|
@rrobinett We may have solved the issue so you can now try the master branch: git clone https://github.com/pothosware/SoapySDRPlay.git
cd SoapySDRPlay
git checkout -b master origin/master
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug
make
sudo make install |
|
does the Debug build type enable the API debug output? It will affect performance, but is good if there are still any issues. |
|
The master master has |
|
yep 0 is right, I was just curious as to the difference between |
|
@SDRplay I wouldn't know, I use CMake-Gui on Windows to configure. I use "Release" and "Release with debug info" configurations exclusively and I don't know if it applies on the other platforms. |
|
Sorry that I've been too busy to test, but I will try in the next several days. Thanks |
|
@SDRplay fix works! CubicSDR can now receive data, though anything over 1 Mhz seems to be too much. |
|
If you've still got debug enabled that will be a problem. Also, 16bit I/Q data will be quite bandwidth hungry at higher sample rates. If the library supports it, you might try 8 bit mode. May @vsonnier can confirm whether that is supported. To be honest remote data is really only suitable for small bandwidths on any system. |
|
@SDRplay Debug is disabled in head now, so it isn't enabled. I have a 1Gbit Ethernet connection, how much bandwidth do we need? Is this an issue of network bandwidth or small SBC's being unable to stuff that bandwidth without dedicated PHY's like RPi? |
|
Most SBCs like the Raspberry Pi have an inherent problem because ALL of the peripheral data is shared on the USB bus including the network port. I'm not sure about the Odroid. I've backed a new SBC on kickstarter (https://www.kickstarter.com/projects/librecomputer/libre-computer-board-tritium-sbc-linux-android-7-n) that doesn't have this shared bandwidth which I hope to receive in the next couple of months and I'll be able to gather some data on throughput. You'll also need to consider the processing requirement and the latency huge sample rates will create. It may be worth seeing if there are any options you can use in SoapyRemote to change the CPU vs bandwidth - maybe @guruofquality or @vsonnier can comment? What sort of sample rate were you expecting? |
|
The Odroid has a dedicated PHY and does not share the bus with USB devices, it's one of the reasons I chose it, along with boatloads more CPU power over the RPi. I can understand latency being an issue, and am happy to work within these limits. Speaking of CPU, I'm awaiting delivery of an all Aluminum case for the Odroid, perhaps that can help with thermal throttling running GQRX and accessing it via remote X. If not, this might a better option: https://www.notebookcheck.net/Benchmarks-for-the-Intel-Hades-Canyon-NUC-with-Core-i7-8809G-CPU-and-RX-Vega-M-GPU-leak-out.287220.0.html |
|
@Strykar you can try CS16 format (the most compact one) and tuning the MTU among other things: |
|
I am finally able to resume work on this. Because my original Pi environment was corrupted I flashed the latest raspberian and am trying to cleanly build Soapy following the instructions of @vsonnier, but I get errors, first in: cmake .. -DCMAKE_BUILD_TYPE=Debug Then when I execute cmake : pi@raspberrypi:~/SoapySDRPlay $ git checkout -b master origin/masterfatal: A branch named 'master' already exists. Add the installation prefix of "SoapySDR" to CMAKE_PREFIX_PATH or set -- Configuring incomplete, errors occurred! What am I doing wrong? |
|
It cant find SoapySDR development files. Did you install SoapySDR? if so can you share the output of make install? |
|
No.
I confess I am lost in the web site looking for instructions on how to set
up this whole development environment
…On Mon, Mar 19, 2018 at 9:36 PM, Josh Blum ***@***.***> wrote:
It cant find SoapySDR development files. Did you install SoapySDR? if so
can you share the output of make install?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AgoIZDoKgFKH1DtRtiBM6GsdtOtLV5Fzks5tgIdTgaJpZM4LbUCD>
.
--
Rob Robinett
rob@robinett.us
|
|
So here is the output: pi@raspberrypi: Soapy SDR -- the SDR abstraction library###################################################### Lib Version: v0.7.0-unknown
|
|
@rrobinett The problem may comes from
And a lack of the Soapy dependencies, like in #35. So: Delete all the SoapySDR , SoapySDRPlay, SoapyRemote directories, (if any) and do the following: From @loughkb scripts. And you need to be root I think to execute them (for the |
|
Thanks for those clear instructions. Unfortunately my build attempt fails
at the same place:
pi@raspberrypi:~ $ rm -rf SoapySDR*
pi@raspberrypi:~ $ git clone https://github.com/pothosware/SoapySDR.git
Cloning into 'SoapySDR'...
remote: Counting objects: 7096, done.
remote: Total 7096 (delta 0), reused 0 (delta 0), pack-reused 7096
Receiving objects: 100% (7096/7096), 3.47 MiB | 2.48 MiB/s, done.
Resolving deltas: 100% (5615/5615), done.
pi@raspberrypi:~ $ git clone https://github.com/pothosware/SoapySDRPlay.git
Cloning into 'SoapySDRPlay'...
remote: Counting objects: 376, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 376 (delta 11), reused 13 (delta 6), pack-reused 355
Receiving objects: 100% (376/376), 107.82 KiB | 0 bytes/s, done.
Resolving deltas: 100% (248/248), done.
pi@raspberrypi:~ $ git clone https://github.com/pothosware/SoapyRemote.git
Cloning into 'SoapyRemote'...
remote: Counting objects: 1791, done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 1791 (delta 26), reused 31 (delta 16), pack-reused 1740
Receiving objects: 100% (1791/1791), 479.39 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1300/1300), done.
pi@raspberrypi:~ $ cd SoapySDR
pi@raspberrypi:~/SoapySDR $ mkdir build
pi@raspberrypi:~/SoapySDR $ cd build
pi@raspberrypi:~/SoapySDR/build $ cmake ..
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type not specified: defaulting to release.
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
--
-- #############################################
-- ## Begin configuration for Python support...
-- #############################################
-- Enabling optional Python bindings if possible...
-- Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
-- SWIG_FOUND: FALSE -
-- Found PythonInterp: /usr/bin/python (found version "2.7.13")
-- PYTHONINTERP_FOUND: TRUE - 2.7.13
-- PYTHON_EXECUTABLE: /usr/bin/python
-- PYTHON_INSTALL_DIR: ${prefix}/lib/python2.7/dist-packages
-- Found PythonLibs: /usr/lib/arm-linux-gnueabihf/libpython2.7.so (found
version "2.7.13")
-- PYTHONLIBS_FOUND: TRUE - 2.7.13
-- PYTHON_INCLUDE_DIRS: /usr/include/python2.7
-- PYTHON_LIBRARIES: /usr/lib/arm-linux-gnueabihf/libpython2.7.so
-- Performing Test SIZE_T_IS_UNSIGNED_INT
-- Performing Test SIZE_T_IS_UNSIGNED_INT - Success
--
-- #############################################
-- ## Begin configuration for Python3 support...
-- #############################################
-- Enabling optional Python3 bindings if possible...
-- Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
-- SWIG_FOUND: FALSE -
-- Found Python3Interp: /usr/bin/python3
-- Could NOT find Python3InterpDbg (missing: PYTHON3_DBG_EXECUTABLE)
-- PYTHON3INTERP_FOUND: TRUE
-- PYTHON3_EXECUTABLE: /usr/bin/python3
-- PYTHON3_INSTALL_DIR: ${prefix}/lib/python3/dist-packages
-- Found Python3Libs: /usr/lib/arm-linux-gnueabihf/libpython3.5m.so
-- PYTHON3LIBS_FOUND: TRUE
-- PYTHON3_INCLUDE_DIRS: /usr/include/python3.5m
-- PYTHON3_LIBRARIES: /usr/lib/arm-linux-gnueabihf/libpython3.5m.so
--
-- ######################################################
-- ## SoapySDR enabled features
-- ######################################################
--
* Library , runtime library v0.7.0-g824d83e8
* Tests , library unit tests
…-- ######################################################
-- ## SoapySDR disabled features
-- ######################################################
--
* Docs , doxygen documentation
* Python , python bindings v2.7.13
* Python3 , python3 bindings
-- SoapySDR version: v0.7.0-g824d83e8
-- ABI/so version: v0.7
-- Install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/SoapySDR/build
pi@raspberrypi:~/SoapySDR/build $ make -j4
Scanning dependencies of target SoapySDR
[ 9%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Device.cpp.o
[ 9%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Registry.cpp.o
[ 9%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Types.cpp.o
[ 12%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Factory.cpp.o
[ 15%] Building CXX object lib/CMakeFiles/SoapySDR.dir/NullDevice.cpp.o
[ 18%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Logger.cpp.o
[ 21%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Errors.cpp.o
[ 25%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Formats.cpp.o
[ 28%] Building CXX object
lib/CMakeFiles/SoapySDR.dir/ConverterRegistry.cpp.o
[ 31%] Building CXX object
lib/CMakeFiles/SoapySDR.dir/DefaultConverters.cpp.o
[ 34%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Modules.cpp.o
[ 37%] Building CXX object lib/CMakeFiles/SoapySDR.dir/Version.cpp.o
[ 40%] Building CXX object lib/CMakeFiles/SoapySDR.dir/TypesC.cpp.o
[ 43%] Building CXX object lib/CMakeFiles/SoapySDR.dir/ModulesC.cpp.o
[ 46%] Building CXX object lib/CMakeFiles/SoapySDR.dir/VersionC.cpp.o
[ 50%] Building CXX object lib/CMakeFiles/SoapySDR.dir/DeviceC.cpp.o
[ 53%] Building CXX object lib/CMakeFiles/SoapySDR.dir/FactoryC.cpp.o
[ 56%] Building CXX object lib/CMakeFiles/SoapySDR.dir/LoggerC.cpp.o
[ 59%] Building CXX object lib/CMakeFiles/SoapySDR.dir/TimeC.cpp.o
[ 62%] Building CXX object lib/CMakeFiles/SoapySDR.dir/ErrorsC.cpp.o
[ 65%] Building CXX object lib/CMakeFiles/SoapySDR.dir/FormatsC.cpp.o
[ 68%] Linking CXX shared library libSoapySDR.so
[ 68%] Built target SoapySDR
Scanning dependencies of target SoapySDRUtil
Scanning dependencies of target TestTimeConversion
Scanning dependencies of target TestFormatParser
Scanning dependencies of target TestKwargsMarkup
[ 71%] Building CXX object
tests/CMakeFiles/TestTimeConversion.dir/TestTimeConversion.cpp.o
[ 75%] Building CXX object
apps/CMakeFiles/SoapySDRUtil.dir/SoapySDRUtil.cpp.o
[ 78%] Building CXX object
tests/CMakeFiles/TestFormatParser.dir/TestFormatParser.cpp.o
[ 81%] Building CXX object
tests/CMakeFiles/TestKwargsMarkup.dir/TestKwargsMarkup.cpp.o
[ 84%] Linking CXX executable TestTimeConversion
[ 84%] Built target TestTimeConversion
[ 87%] Building CXX object
apps/CMakeFiles/SoapySDRUtil.dir/SoapySDRProbe.cpp.o
[ 90%] Linking CXX executable TestFormatParser
[ 90%] Built target TestFormatParser
[ 93%] Building CXX object
apps/CMakeFiles/SoapySDRUtil.dir/SoapyRateTest.cpp.o
[ 96%] Linking CXX executable TestKwargsMarkup
[ 96%] Built target TestKwargsMarkup
[100%] Linking CXX executable SoapySDRUtil
[100%] Built target SoapySDRUtil
pi@raspberrypi:~/SoapySDR/build $ make install
[ 68%] Built target SoapySDR
[ 81%] Built target SoapySDRUtil
[ 87%] Built target TestTimeConversion
[ 93%] Built target TestFormatParser
[100%] Built target TestKwargsMarkup
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/share/cmake/SoapySDR/SoapySDRConfig.cmake
CMake Error at cmake_install.cmake:36 (file):
file INSTALL cannot copy file
"/home/pi/SoapySDR/cmake/Modules/SoapySDRConfig.cmake" to
"/usr/local/share/cmake/SoapySDR/SoapySDRConfig.cmake".
Makefile:72: recipe for target 'install' failed
make: *** [install] Error 1
pi@raspberrypi:~/SoapySDR/build $ sudo make install
[ 68%] Built target SoapySDR
[ 81%] Built target SoapySDRUtil
[ 87%] Built target TestTimeConversion
[ 93%] Built target TestFormatParser
[100%] Built target TestKwargsMarkup
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/share/cmake/SoapySDR/SoapySDRConfig.cmake
-- Installing: /usr/local/share/cmake/SoapySDR/SoapySDRUtil.cmake
-- Installing: /usr/local/share/cmake/SoapySDR/SoapySDRConfigVersion.cmake
-- Up-to-date: /usr/local/include/SoapySDR
-- Installing: /usr/local/include/SoapySDR/Device.h
-- Installing: /usr/local/include/SoapySDR/Version.hpp
-- Installing: /usr/local/include/SoapySDR/ConverterPrimatives.hpp
-- Installing: /usr/local/include/SoapySDR/Errors.h
-- Installing: /usr/local/include/SoapySDR/Logger.hpp
-- Installing: /usr/local/include/SoapySDR/Time.hpp
-- Installing: /usr/local/include/SoapySDR/Types.hpp
-- Installing: /usr/local/include/SoapySDR/Modules.hpp
-- Installing: /usr/local/include/SoapySDR/ConverterRegistry.hpp
-- Installing: /usr/local/include/SoapySDR/Config.h
-- Installing: /usr/local/include/SoapySDR/Registry.hpp
-- Installing: /usr/local/include/SoapySDR/Formats.hpp
-- Installing: /usr/local/include/SoapySDR/Config.hpp
-- Installing: /usr/local/include/SoapySDR/Errors.hpp
-- Installing: /usr/local/include/SoapySDR/Modules.h
-- Installing: /usr/local/include/SoapySDR/Types.h
-- Installing: /usr/local/include/SoapySDR/Time.h
-- Installing: /usr/local/include/SoapySDR/Device.hpp
-- Installing: /usr/local/include/SoapySDR/Version.h
-- Installing: /usr/local/include/SoapySDR/Logger.h
-- Installing: /usr/local/include/SoapySDR/Constants.h
-- Installing: /usr/local/include/SoapySDR/Formats.h
-- Installing: /usr/local/lib/libSoapySDR.so.0.7.0
-- Up-to-date: /usr/local/lib/libSoapySDR.so.0.7
-- Up-to-date: /usr/local/lib/libSoapySDR.so
-- Installing: /usr/local/lib/pkgconfig/SoapySDR.pc
-- Installing: /usr/local/bin/SoapySDRUtil
-- Set runtime path of "/usr/local/bin/SoapySDRUtil" to ""
-- Installing: /usr/local/share/man/man1/SoapySDRUtil.1
pi@raspberrypi:~/SoapySDR/build $ sudo ldconfig
pi@raspberrypi:~/SoapySDR/build $ cd ../..
pi@raspberrypi:~ $ cd SoapySDRPlay/
pi@raspberrypi:~/SoapySDRPlay $ mkdir build
pi@raspberrypi:~/SoapySDRPlay $ cd build
pi@raspberrypi:~/SoapySDRPlay/build $ cmake ..
-- The CXX compiler identification is GNU 6.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type not specified: defaulting to release.
-- libsdrplay not found.
CMake Error at CMakeLists.txt:16 (message):
SDRPlay development files not found...
-- Configuring incomplete, errors occurred!
See also "/home/pi/SoapySDRPlay/build/CMakeFiles/CMakeOutput.log".
pi@raspberrypi:~/SoapySDRPlay/build $
On Mon, Mar 19, 2018 at 10:57 PM, Vincent Sonnier ***@***.***> wrote:
@rrobinett <https://github.com/rrobinett> The problem comes from
fatal: A branch named 'master' already exists.
Delete all the SoapySDR , SoapySDRPlay, SoapyRemote directories, and do
the following:
git clone https://github.com/pothosware/SoapySDR.git
git clone https://github.com/pothosware/SoapySDRPlay.git
git clone https://github.com/pothosware/SoapyRemote.git
cd SoapySDR
mkdir build
cd build
cmake ..
make -j4
make install
ldconfig
cd ..
cd ..
# Now we build the SDRPlay module for Soapy
cd SoapySDRPlay
mkdir build
cd build
cmake ..
make
make install
cd ..
cd ..
# And we build SoapyRemote
cd SoapyRemote
mkdir build
cd build
#cmake ..
cmake .. -DCMAKE_BUILD_TYPE=Release
make
make install
cd ..
cd ..
(From @loughkb <https://github.com/loughkb> scripts)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AgoIZKMl4LnLNSBGIsnsltBVSPPvSqdZks5tgJpbgaJpZM4LbUCD>
.
--
Rob Robinett
rob@robinett.us
|
|
Sorry, I was building on a fresh raspberrian OS and had failed to download and install the SDRPlay driver from their site. Having done that I have been able to build and run SDRServer. However I do get some compile warning messages and I am missing the Avanhi library. How do I get that? thanks =============== |
|
That's an optional library. As the note says, install libavahi... sudo apt-get install libavahi-client-dev |
|
So it looks like this bug got sorted out in soapysdrplay. Its quite a long issue that this point, and it wasn't really an issue for the SoapyRemote codebase. I'm going to close it out. Thanks for everyones help in tracking this down! |
Using the Osmocom source block with Soapy Remote, I sometimes get a segfault:
Here is what GNUradio says:
Here is what the remote server running SoapySDRServer says right before it segfaults:
Is this because the server cannot keep up with the requested sample rate?
The text was updated successfully, but these errors were encountered: