Startup Crash on MacPro Tower with 2 Screens.

[g0oan]

Hi Cjcliffe,

Thank you once again for resolving my earlier 'not compatible' problem.

I'm now in the process of trying CubicSDR on my MacPro tower which has two screens and runs OS 10.11 (El Capitan).

What happens is that as soon as the programme tries to launch I can very briefly see the dialog box to select the RTL dongle. It flashes briefly on screen, for just a second or two, and then disappears.

CubicSDR then crashes with the system reporting that CubicSDR has unexpectedly quit.

Crash log is below. I've only included the top part of the log but if you need all of it please let me know. It appears to have something to do with libliquid.

Thanks again for all of the help.

Kind regards,

Sean.

Process: CubicSDR [3869] Path: /Applications/CubicSDR.app/Contents/MacOS/CubicSDR Identifier: com.cubicproductions.cubicsdr Version: 0.2.0 (0.2.0-beta-rc4) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: CubicSDR [3869] User ID: 501

Date/Time: 2016-07-16 10:05:14.241 +0100 OS Version: Mac OS X 10.11.5 (15F34) Report Version: 11 Anonymous UUID: C0C78AB8-18BD-8171-E25A-B2955CFFB003

Time Awake Since Boot: 80000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libliquid.dylib 0x0000000105e1f4c8 firhilbf_create + 264 1 libliquid.dylib 0x0000000105e704fe ampmodem_create + 158 2 com.cubicproductions.cubicsdr 0x000000010538170d ModemAM::ModemAM() + 45 3 com.cubicproductions.cubicsdr 0x00000001053416c6 CubicSDR::OnInit() + 246 4 com.cubicproductions.cubicsdr 0x00000001054fe09e wxApp::CallOnInit() + 158 5 com.cubicproductions.cubicsdr 0x0000000105479296 wxEntry(int&, wchar_t**) + 38 6 com.cubicproductions.cubicsdr 0x0000000105340650 main + 48 7 libdyld.dylib 0x00007fff97df75ad start + 1

Thread 1: 0 libsystem_kernel.dylib 0x00007fff903c05e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a08b578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff8a089341 start_wqthread + 13

Thread 2:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff903c0efa kevent_qos + 10 1 libdispatch.dylib 0x00007fff957e6165 _dispatch_mgr_invoke + 216 2 libdispatch.dylib 0x00007fff957e5dcd _dispatch_mgr_thread + 52

Thread 3: 0 libsystem_kernel.dylib 0x00007fff903c05e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a08b578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff8a089341 start_wqthread + 13

Thread 4: 0 libsystem_kernel.dylib 0x00007fff903c05e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a08b578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff8a089341 start_wqthread + 13

Thread 5: 0 libsystem_kernel.dylib 0x00007fff903c05e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8a08b578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff8a089341 start_wqthread + 13

Thread 6:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x00007fff903b9fae semaphore_wait_trap + 10 1 libdispatch.dylib 0x00007fff957ebcb2 _dispatch_semaphore_wait_slow + 224 2 com.apple.HIToolbox 0x00007fff868ff9e1 _BeginEventReceiptOnThread + 151 3 com.apple.AppKit 0x00007fff98b2ad33 _NSEventThread + 51 4 libsystem_pthread.dylib 0x00007fff8a08b99d _pthread_body + 131 5 libsystem_pthread.dylib 0x00007fff8a08b91a _pthread_start + 168 6 libsystem_pthread.dylib 0x00007fff8a089351 thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000024 rbx: 0x0000000000000000 rcx: 0x00007fff92f2a1a8 rdx: 0x00000000ffff7b00 rdi: 0x0000000000000024 rsi: 0x0000000000000025 rbp: 0x00007fff5a8c6a10 rsp: 0x00007fff5a8c69e0 r8: 0x0000000000000004 r9: 0x00000000ffffffc0 r10: 0x00007fff9c39bb00 r11: 0x00007fff92f0b470 r12: 0x00007feab0e3f9f0 r13: 0x00007feab0e3f9a0 r14: 0x00007feab0e40ce0 r15: 0x0000000000000025 rip: 0x0000000105e1f4c8 rfl: 0x0000000000010246 cr2: 0x0000000105e590e0

Logical CPU: 0 Error Code: 0x00000000 Trap Number: 6

[cjcliffe]

@g0oan I've seen this before -- there's an instance of each modem created on startup to use as a factory and some of the constructors to initialize the factories create liquid-dsp objects -- I've made an adjustment so that there's just factory() functions for each modem now instead of a sub-class method so it won't try to initialize unused modems and liquid-dsp objects on startup.

Here's a test build that shouldn't make any modems or calls to modem functions until one is actually added:

CubicSDR-0.2.0-Darwin-rc4-liquid_startup_crash.dmg.zip

If that doesn't fix the issue it should hopefully unmask it and show something else.

[g0oan]

Hi There,

Thank you so much for taking the time to look into this, I really appreciate all of the effort.

Same response I’m afraid. The dialog box used to select the input method flashes briefly on screen, then the programme crashes, sorry,

I’ve attached the system report below which I hope is helpful.

Thank you once again for all of the hard work.

Sean.

Process: CubicSDR [1253] Path: /Applications/CubicSDR.app/Contents/MacOS/CubicSDR Identifier: com.cubicproductions.cubicsdr Version: 0.2.0 (0.2.0-beta-rc4) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: CubicSDR [1253] User ID: 501

Date/Time: 2016-07-24 20:42:24.037 +0100 OS Version: Mac OS X 10.11.6 (15G31) Report Version: 11 Anonymous UUID: C0C78AB8-18BD-8171-E25A-B2955CFFB003

Time Awake Since Boot: 40000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libliquid.dylib 0x0000000104430748 fft_create_plan_mixed_radix + 568 1 libliquid.dylib 0x00000001044306d0 fft_create_plan_mixed_radix + 448 2 com.cubicproductions.cubicsdr 0x00000001039e6d2d SpectrumVisualProcessor::setup(unsigned int) + 317 3 com.cubicproductions.cubicsdr 0x00000001039718a6 AppFrame::AppFrame() + 3078 4 com.cubicproductions.cubicsdr 0x0000000103966adc CubicSDR::OnInit() + 3052 5 com.cubicproductions.cubicsdr 0x0000000103b22ffe wxApp::CallOnInit() + 158 6 com.cubicproductions.cubicsdr 0x0000000103a9e1f6 wxEntry(int&, wchar_t**) + 38 7 com.cubicproductions.cubicsdr 0x0000000103964f70 main + 48 8 libdyld.dylib 0x00007fff904355ad start + 1

Thread 1: 0 libsystem_kernel.dylib 0x00007fffa10755e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9cb3e578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff9cb3c341 start_wqthread + 13

Thread 2:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fffa1075efa kevent_qos + 10 1 libdispatch.dylib 0x00007fff966bb165 _dispatch_mgr_invoke + 216 2 libdispatch.dylib 0x00007fff966badcd _dispatch_mgr_thread + 52

Thread 3: 0 libsystem_kernel.dylib 0x00007fffa10755e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9cb3e578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff9cb3c341 start_wqthread + 13

Thread 4: 0 libsystem_kernel.dylib 0x00007fffa10755e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9cb3e578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff9cb3c341 start_wqthread + 13

Thread 5: 0 libsystem_kernel.dylib 0x00007fffa10755e2 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9cb3e578 _pthread_wqthread + 1283 2 libsystem_pthread.dylib 0x00007fff9cb3c341 start_wqthread + 13

Thread 6:

Thread 7:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x00007fffa106efae semaphore_wait_trap + 10 1 libdispatch.dylib 0x00007fff966c0cb2 _dispatch_semaphore_wait_slow + 224 2 com.apple.HIToolbox 0x00007fff8e4949e1 _BeginEventReceiptOnThread + 151 3 com.apple.AppKit 0x00007fff9560ad33 _NSEventThread + 51 4 libsystem_pthread.dylib 0x00007fff9cb3e99d _pthread_body + 131 5 libsystem_pthread.dylib 0x00007fff9cb3e91a _pthread_start + 168 6 libsystem_pthread.dylib 0x00007fff9cb3c351 thread_start + 13

Thread 8: 0 libsystem_kernel.dylib 0x00007fffa1074db6 psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff9cb3f728 _pthread_cond_wait + 767 2 libc++.1.dylib 0x00007fff9b7c868f std::__1::condition_variable::wait(std::1::unique_lockstd::1::mutex&) + 47 3 com.cubicproductions.cubicsdr 0x000000010398e18b SDRPostThread::run() + 459 4 com.cubicproductions.cubicsdr 0x000000010398993f IOThread::threadMain() + 31 5 com.cubicproductions.cubicsdr 0x000000010396aab2 void* std::1::__thread_proxy<std::__1::tuple<void (IOThread::)(), SDRPostThread> >(void) + 114 6 libsystem_pthread.dylib 0x00007fff9cb3e99d _pthread_body + 131 7 libsystem_pthread.dylib 0x00007fff9cb3e91a _pthread_start + 168 8 libsystem_pthread.dylib 0x00007fff9cb3c351 thread_start + 13

Thread 9: 0 libsystem_kernel.dylib 0x00007fffa107510a semwait_signal + 10 1 libsystem_c.dylib 0x00007fff8c569d0f nanosleep + 199 2 libc++.1.dylib 0x00007fff9b807020 std::1::this_thread::sleep_for(std::1::chrono::duration<long long, std::1::ratio<1l, 1000000000l> > const&) + 75 3 com.cubicproductions.cubicsdr 0x00000001039eb2b1 SpectrumVisualDataThread::run() + 65 4 com.cubicproductions.cubicsdr 0x000000010398993f IOThread::threadMain() + 31 5 com.cubicproductions.cubicsdr 0x000000010396ab52 void* std::1::thread_proxy<std::__1::tuple<void (IOThread::)(), SpectrumVisualDataThread> >(void) + 114 6 libsystem_pthread.dylib 0x00007fff9cb3e99d _pthread_body + 131 7 libsystem_pthread.dylib 0x00007fff9cb3e91a _pthread_start + 168 8 libsystem_pthread.dylib 0x00007fff9cb3c351 thread_start + 13

Thread 10: 0 libsystem_kernel.dylib 0x00007fffa107510a semwait_signal + 10 1 libsystem_c.dylib 0x00007fff8c569d0f nanosleep + 199 2 libc++.1.dylib 0x00007fff9b807020 std::1::this_thread::sleep_for(std::1::chrono::duration<long long, std::1::ratio<1l, 1000000000l> > const&) + 75 3 com.cubicproductions.cubicsdr 0x00000001039eb2b1 SpectrumVisualDataThread::run() + 65 4 com.cubicproductions.cubicsdr 0x000000010398993f IOThread::threadMain() + 31 5 com.cubicproductions.cubicsdr 0x000000010396ab52 void* std::1::thread_proxy<std::__1::tuple<void (IOThread::)(), SpectrumVisualDataThread> >(void) + 114 6 libsystem_pthread.dylib 0x00007fff9cb3e99d _pthread_body + 131 7 libsystem_pthread.dylib 0x00007fff9cb3e91a _pthread_start + 168 8 libsystem_pthread.dylib 0x00007fff9cb3c351 thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000001 rbx: 0x0000000000000000 rcx: 0x00000001044aab20 rdx: 0x0000000000000400 rdi: 0x000000010459ce00 rsi: 0x000000010459ce00 rbp: 0x00007fff5c2a1220 rsp: 0x00007fff5c2a10f0 r8: 0x0000000000000000 r9: 0x0000000000000003 r10: 0x00000000d177f55f r11: 0x00000000d1788b46 r12: 0x00007f8b72f480a0 r13: 0x0000000000000080 r14: 0x00007f8b7483d000 r15: 0x0000000000000001 rip: 0x0000000104430748 rfl: 0x0000000000010202 cr2: 0x0000000101adb000

Logical CPU: 0 Error Code: 0x0200014e Trap Number: 133

On 24 Jul 2016, at 20:33, Charles J. Cliffe <notifications@github.com mailto:notifications@github.com> wrote:

@g0oan https://github.com/g0oan I've seen this before -- there's an instance of each modem created on startup to use as a factory and some of the constructors to initialize the factories create liquid-dsp objects -- I've made an adjustment so that there's just factory() functions for each modem now instead of a sub-class method so it won't try to initialize unused modems and liquid-dsp objects on startup.

Here's a test build that shouldn't make any modems or calls to modem functions until one is actually added:

CubicSDR-0.2.0-Darwin-rc4-liquid_startup_crash.dmg.zip https://github.com/cjcliffe/CubicSDR/files/380458/CubicSDR-0.2.0-Darwin-rc4-liquid_startup_crash.dmg.zip If that doesn't fix the issue it should hopefully unmask it and show something else.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/406#issuecomment-234797199, or mute the thread https://github.com/notifications/unsubscribe-auth/ATC6eD4a9xhzqAGv4DU2yJlVSQjbLyyxks5qY74igaJpZM4JN-aY.

[cjcliffe]

@g0oan I've tried re-building liquid-dsp with latest updates and checking build flags; let me know if either of these test builds change anything:

CubicSDR-0.2.0-Darwin-rc4_startup_crash2.dmg.zip

or

CubicSDR-0.2.0-Darwin-rc4_startup_crash3.dmg.zip

Thanks!

[g0oan]

Hi Charles,

Still freezing I’m afraid.

The crash log points to the same problem with both versions,

Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libliquid.dylib 0x000000010b258748 fft_create_plan_mixed_radix + 568 1 libliquid.dylib 0x000000010b2586d0 fft_create_plan_mixed_radix + 448 2 com.cubicproductions.cubicsdr 0x000000010a80ed2d SpectrumVisualProcessor::setup(unsigned int) + 317 3 com.cubicproductions.cubicsdr 0x000000010a7998a6 AppFrame::AppFrame() + 3078 4 com.cubicproductions.cubicsdr 0x000000010a78eadc CubicSDR::OnInit() + 3052 5 com.cubicproductions.cubicsdr 0x000000010a94affe wxApp::CallOnInit() + 158 6 com.cubicproductions.cubicsdr 0x000000010a8c61f6 wxEntry(int&, wchar_t**) + 38 7 com.cubicproductions.cubicsdr 0x000000010a78cf70 main + 48 8 libdyld.dylib 0x00007fff8a9c25ad start + 1

From what I understand of it, and I could easily be wrong, the SIGILL exception type is an attempt "to execute an illegal, malformed, unknown, or privileged instruction.” and Thread 0 seems to be indicating some sort of issue with libliquid.dylib’s, fft_create_plan_mixed_radix file.

But again, I could oh so easily be wrong about that one :)

Hope this helps.

Kind regards,

Sean.

On 24 Jul 2016, at 23:43, Charles J. Cliffe <notifications@github.com mailto:notifications@github.com> wrote:

@g0oan https://github.com/g0oan I've tried re-building liquid-dsp with latest updates and checking build flags; let me know if either of these test builds change anything:

CubicSDR-0.2.0-Darwin-rc4_startup_crash2.dmg.zip https://github.com/cjcliffe/CubicSDR/files/380527/CubicSDR-0.2.0-Darwin-rc4_startup_crash2.dmg.zip or

CubicSDR-0.2.0-Darwin-rc4_startup_crash3.dmg.zip https://github.com/cjcliffe/CubicSDR/files/380531/CubicSDR-0.2.0-Darwin-rc4_startup_crash3.dmg.zip Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/406#issuecomment-234807504, or mute the thread https://github.com/notifications/unsubscribe-auth/ATC6eOjLP73JMRK-G0wTJP3Vpnjcohpoks5qY-p1gaJpZM4JN-aY.

[cjcliffe]

@g0oan It seems to crash attempting to execute anything liquid-dsp related; the bundled lib appears to be signed correctly and built for 10.9 from what I can tell.

If you open a Terminal.app and run like this with sudo does it change anything? --

 sudo /Applications/CubicSDR.app/Contents/MacOS/CubicSDR

[g0oan]

Hi Charles,

Same thing I’m afraid, still crashing at,

0 libliquid.dylib 0x0000000108208b8a fft_create_plan_mixed_radix + 554 1 libliquid.dylib 0x0000000108208b20 fft_create_plan_mixed_radix + 448

I’ve download the source code for liquid-dsp and compiled it on my Mac, which it seemed to do OK.

Any tests I can run just to check the version I’ve built. Just trying to check if there is any disparity between my hardware and liquid-dsp.

Kind regards,

Sean.

On 25 Jul 2016, at 17:58, Charles J. Cliffe <notifications@github.com mailto:notifications@github.com> wrote:

@g0oan https://github.com/g0oan It seems to crash attempting to execute anything liquid-dsp related; the bundled lib appears to be signed correctly and built for 10.9 from what I can tell.

If you open a Terminal.app and run like this with sudo does it change anything? --

sudo /Applications/CubicSDR.app/Contents/MacOS/CubicSDR — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/406#issuecomment-235014451, or mute the thread https://github.com/notifications/unsubscribe-auth/ATC6eD44G_C9skMtZbfvDQuRfMYkEIdiks5qZOs1gaJpZM4JN-aY.

[cjcliffe]

@g0oan assuming you've already run sudo make install for liquid-dsp and it came from the master branch (not the releases zip) and installed CubicSDR.app to /Applications/; can you try running the following from Terminal.app:

cp /usr/local/lib/libliquid.dylib /Applications/CubicSDR.app/Contents/MacOS/

If for some reason the build of liquid-dsp was different for your platform this should make it compatible -- note the .app signing will be broken afterwards and likely won't want to run if copied to another system.

[g0oan]

Hi Charles,

Pleased to say we’re making progress.

It would appear that the libliquid.dy.lib I built yesterday compiled OK and copied into CubicSDR.app just fine.

CubicSDR now launches and runs.

Couple of things I’ve noticed.

1. When I first launch CubicSDR I don’t see the “CubicSDR:: SDR Devices” window, the one which lets you select the input device. The program simple launches straight into the main screen but it does however appear to automatically select the RTL Dongle which I am using.
2. I’ve also noticed from watching the Console output that as the program launches it creates two error messages,

27/07/2016 10:01:32.576 launchservicesd[86]: SecTaskLoadEntitlements failed error=22 27/07/2016 10:01:32.576 launchservicesd[86]: SecTaskLoadEntitlements failed error=22

From what I can understand of it, and I might well be wrong, SecTaskLoadEntitlements errors relate to the application’s entitlements as defined in the plist file. I gather that it is indicating that the “launchd” program tried to load in the entitlements for CubicSDR but failed with the error number 22. Error 22 I believe means that an invalid argument or parameter was given.

Might it have something to do with the System Integrity Protection in Mac OS El Capitan?

1. Also when the program gets up and running there is something rather curious about CubicSDR's screen updates. I’ve include a little video so that you can see for yourself. In short the CubicSDR screen updates stop whenever I stop moving the mouse around the screen. As you’ll see the only way to keep CubicSDR's screen updating is to constantly keep moving the mouse around the screen. I’ve no idea why I’m afraid. In case you wondering the 73.620Mhz if the IF output from my FT-1000D. I’m trying to use CubicSDR and the RTL as a pan-adaptor for my rig. :)

Thank you once again for all of the hard work with this, really appreciate all of the effort.

Hope this helps.

Sean.

On 26 Jul 2016, at 22:24, Charles J. Cliffe <notifications@github.com mailto:notifications@github.com> wrote:

@g0oan https://github.com/g0oan assuming you've already run sudo make install for liquid-dsp and it came from the master branch (not the releases zip) and installed CubicSDR.app to /Applications/; can you try running the following from Terminal.app:

cp /usr/local/lib/libliquid.dylib /Applications/CubicSDR.app/Contents/MacOS/ If for some reason the build of liquid-dsp was different for your platform this should make it compatible -- note the .app signing will be broken afterwards and likely won't want to run if copied to another system.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/406#issuecomment-235408364, or mute the thread https://github.com/notifications/unsubscribe-auth/ATC6eFpjKmFkrb9qwHtYaubJ_gG5LtdOks5qZnskgaJpZM4JN-aY.

[g0oan]

Hi Charles,

I’ve just successfully used Homebrew to install and build CubicSDR v0.2.0-beta-rc4 on my machine.

Worked first time out of the box, the "CubicSDR:: SDR Devices” window appeared as the program launched and allowed me to select my RTL Dongle.

After that, program completed launch as normal and the Brew version is now working as expected on my machine.

Don’t know if there are any logs or anything I can send you that might help give you some insight.

Hope this helps.

Kind regards,

Sean.

[cjcliffe]

@g0oan I'm at a loss; though it's rather strange the items you describe above:

1 - The devices window has been there since SoapySDR releases; the only version that didn't have it is old, unsigned and RTL-SDR only. The old builds are also the only ones that launche the RTL-SDR immediately; there's no such code do to that in the SoapySDR builds. 2 - The latest builds in the last few months should all be signed with my Developer ID and shouldn't trigger any security/integrity I'd hope 3 - This bug you describe was resolved sometime last year I believe but would still persist in an old RTL-SDR build.

I think you might have had an old build running on the desktop perhaps? Rebuilding from source would definitely bring you up to date.

Glad to hear the homebrew solution is working; If there's still a problem with the 0.2.0 builds going forward I'll keep this in mind to see if anyone else hits this issue so that we can pool information.