Skip to content

SDR++ crashes on start with Fobos SDR attached #19

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
Closed
alexey-lysiuk opened this issue Mar 22, 2025 · 2 comments · May be fixed by #20
Closed

SDR++ crashes on start with Fobos SDR attached #19

alexey-lysiuk opened this issue Mar 22, 2025 · 2 comments · May be fixed by #20

Comments

@alexey-lysiuk
Copy link

The issue was reported in AlexandreRouma/SDRPlusPlus#1600 initially, but it was closed with suggestion to report it here.

Hardware

  • CPU: Intel Core i7-8700B
  • RAM: 64 GB
  • GPU: Intel UHD Graphics 630
  • SDR: Local

Software

  • Operating System: macOS 15.3.2
  • SDR++: v1.2.1 (Built at 15:54:45, Mar 12 2025), it's a build artifact of aa2b4b1c5814cc2f832898a9e4a1bdfc38e7ac8d, HEAD as of now

Bug Description

Attempt to start SDR++ on macOS with Fobos SDR attached crashes during initialization.
If device is connected when SDR++ is already running, everything works correctly.

Steps To Reproduce

  1. Attach to to Mac
  2. Run SDR++
  3. Main window appears but closes during loading of source modules

Only If SDR++ fails to lauch or the SDR fails to start:

[INFO] SDR++ v1.2.1
[INFO] Loading config
[WARN] ConfigManager locked, waiting...
[ERROR] Glfw Error 65548: Cocoa: Regular windows do not have icons on macOS
[INFO] Loading icons
[INFO] Loading band plans
[INFO] Loading band plans color table
[INFO] Loading modules
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/airspy_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/airspyhf_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/audio_sink.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/bladerf_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/discord_integration.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/file_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/fobossdr_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/frequency_manager.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/hackrf_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/hermes_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/limesdr_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/m17_decoder.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/meteor_demodulator.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/network_sink.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/network_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/new_portaudio_sink.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/perseus_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/plutosdr_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/radio.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/recorder.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/rfnm_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/rfspace_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/rigctl_client.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/rigctl_server.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/rtl_sdr_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/rtl_tcp_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/scanner.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/sdrplay_source.dylib
[ERROR] Couldn't load SDR++.app/Contents/Resources/../Plugins/sdrplay_source.dylib: dlopen(SDR++.app/Contents/Resources/../Plugins/sdrplay_source.dylib, 0x0005): Library not loaded: @rpath/libsdrplay_api.so.3
  Referenced from: <D855F8E6-853F-35BF-AC63-A4BCC76FBEA1> SDR++.app/Contents/Plugins/sdrplay_source.dylib
  Reason: tried: 'SDR++.app/Contents/Plugins/../Frameworks/libsdrplay_api.so.3' (no such file), 'SDR++.app/Contents/Plugins/../Frameworks/libsdrplay_api.so.3' (no such file), 'SDR++.app/Contents/Frameworks/../Frameworks/libsdrplay_api.so.3' (no such file), 'SDR++.app/Contents/MacOS/../Frameworks/libsdrplay_api.so.3' (no such file)
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/sdrpp_server_source.dylib
[INFO] Loading SDR++.app/Contents/Resources/../Plugins/spyserver_source.dylib
[INFO] Initializing Airspy Source (airspy_source)
[INFO] Initializing AirspyHF+ Source (airspyhf_source)
[INFO] Initializing Audio Sink (audio_sink)
[INFO] Initializing Audio Source (audio_source)
[ERROR] Module 'audio_source' doesn't exist
[INFO] Initializing BladeRF Source (bladerf_source)
[ERROR] Could not list devices -7
[INFO] Initializing File Source (file_source)
[INFO] Initializing FobosSDR Source (fobossdr_source)
[INFO] New DSP samplerate: 50000000.000000 (source samplerate is 50000000.000000)
[INFO] Initializing Frequency Manager (frequency_manager)
[INFO] Initializing HackRF Source (hackrf_source)
zsh: segmentation fault  ./SDR++.app/Contents/MacOS/sdrpp

Screenshots

N/A

Additional info

Here is a stack trace from LLDB

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x28)
  * frame #0: 0x00007ff815ca9500 libsystem_pthread.dylib`pthread_mutex_lock + 4
    frame #1: 0x000000010e688976 libusb-1.0.0.dylib`libusb_get_device_list + 261
    frame #2: 0x000000010e7c2114 libhackrf.0.dylib`hackrf_device_list + 88
    frame #3: 0x000000010e7a786a hackrf_source.dylib`HackRFSourceModule::refresh() + 74
    frame #4: 0x000000010e7a6267 hackrf_source.dylib`HackRFSourceModule::HackRFSourceModule(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>) + 295
    frame #5: 0x000000010e7a5cf3 hackrf_source.dylib`_CREATE_INSTANCE_ + 51
    frame #6: 0x0000000100369dc1 libsdrpp_core.dylib`ModuleManager::createInstance(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>) + 561
    frame #7: 0x000000010027d5c3 libsdrpp_core.dylib`MainWindow::init() + 6851
    frame #8: 0x00000001002520ad libsdrpp_core.dylib`sdrpp_main(int, char**) + 22829
    frame #9: 0x00007ff81591f2cd dyld`start + 1805

Renaming hackrf_source.dylib allows loading of modules to proceed a bit further, but still crashes.

[INFO] Initializing HackRF Source (hackrf_source)
[ERROR] Module 'hackrf_source' doesn't exist
[INFO] Initializing Harogic Source (harogic_source)
[ERROR] Module 'harogic_source' doesn't exist
[INFO] Initializing Hermes Source (hermes_source)
[INFO] Initializing LimeSDR Source (limesdr_source)
Init Error -99
zsh: segmentation fault  ./SDR++.app/Contents/MacOS/sdrpp

 thread #46, stop reason = EXC_BAD_ACCESS (code=1, address=0x128)
  * frame #0: 0x00007ff815ca9500 libsystem_pthread.dylib`pthread_mutex_lock + 4
    frame #1: 0x000000010e690dc0 libusb-1.0.0.dylib`libusb_get_next_timeout + 118
    frame #2: 0x000000010e69057a libusb-1.0.0.dylib`get_next_timeout + 26
    frame #3: 0x000000010e690436 libusb-1.0.0.dylib`libusb_handle_events_timeout_completed + 148
    frame #4: 0x000000010eefacd6 libLimeSuite.23.11-1.dylib`lime::ConnectionFX3Entry::handle_libusb_events() + 86
    frame #5: 0x000000010eefbd13 libLimeSuite.23.11-1.dylib`void* std::__1::__thread_proxy[abi:v160006]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (lime::ConnectionFX3Entry::*)(), lime::ConnectionFX3Entry*>>(void*) + 67
    frame #6: 0x00007ff815cae253 libsystem_pthread.dylib`_pthread_start + 99
    frame #7: 0x00007ff815ca9bef libsystem_pthread.dylib`thread_start + 15

For some reason, libusb context is nullptr in both cases. It seems like Fobos SDR device enumeration breaks initialization process of source module that depends on libusb (when other module is loaded after Fobos SDR one, and Fobos SDR device is connected when its enumeration happens).
@rigexpert
Copy link
Owner

To check the Fobos SDR device API library operation please use fobos_devinfo utility from the current repo. Please read README carefully and follow all the instructions.

All issues related to Alexandre Rouma SDR++ as well ass his fobossdr_source please report to him.

All issues related to libusb please report to https://github.com/libusb/libusb

Actually your sdrpp segfaulted at hackrf_source initialization
[INFO] Initializing HackRF Source (hackrf_source)
zsh: segmentation fault ./SDR++.app/Contents/MacOS/sdrpp

@alexey-lysiuk
Copy link
Author

Please read my report carefully.

Attempt to start SDR++ on macOS with Fobos SDR attached crashes during initialization.
If device is connected when SDR++ is already running, everything works correctly.

It seems like Fobos SDR device enumeration breaks initialization process of source module that depends on libusb (when other module is loaded after Fobos SDR one, and Fobos SDR device is connected when its enumeration happens).

And please read SDR++ author response as well, AlexandreRouma/SDRPlusPlus#1600.

Probably a bug in libfobos breaking libusb, nothing I can do about it. Report it to the fobossdr devs.

With HackRF attached, SDR++ doesn't crash during initialization of LimeSDR plugin. It's the next plugin that depends on libusb.
With FobosSDR attached, the next with libusb as dependency will crash, no matter if the corresponding device is attached or not, no matter if it's HackRF or LimeSDR.

alexey-lysiuk added a commit to alexey-lysiuk/libfobos that referenced this issue Apr 4, 2025
@alexey-lysiuk
Fix dangling device references after successful device opening
276b8fd 
These erroneous references to devices prevented further usage of libusb on macOS
A bunch of the following errors were reported during call to libusb_exit()
> libusb: error [darwin_cleanup_devices] device still referenced at libusb_exit
The next call to libusb_init() failed with the following error
> libusb: error [darwin_first_time_init] libusb_device reference not released on last exit. will not continue

To reproduce the issue, it's enough to add the second call to get_devinfo() function to fobos_devinfo_main.c
Without this change, the second enumeration could not find any devices with FobosSDR connected

Fix rigexpert#19
@alexey-lysiuk alexey-lysiuk mentioned this issue Apr 4, 2025
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

Successfully merging a pull request may close this issue.

Fix dangling device references after successful device opening alexey-lysiuk/libfobos
2 participants
@alexey-lysiuk @rigexpert