Opened 7 years ago
Closed 7 years ago
#54614 closed defect (fixed)
gr-fosphor @20160522_4 crashes when running
Reported by: | roythompson (Roy Thompson) | Owned by: | michaelld (Michael Dickens) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.4.1 |
Keywords: | Cc: | ||
Port: | gr-fosphor |
Description
After installing gr-fosphor on OSX Sierra 10.12.6, it always crashes with this message whenever I try to run any GNU Radio flowgraph with a gr-fosphor sink. I have tried completely wiping and re-installing ports from scratch several times, and always get this error.
2017-08-15 10:10:41.119 Python[51516:919968] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!' *** First throw call stack: ( 0 CoreFoundation 0x00007fff9ae9f2cb __exceptionPreprocess + 171 1 libobjc.A.dylib 0x00007fffafcaf48d objc_exception_throw + 48 2 AppKit 0x00007fff9908ae82 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 4480 3 libglfw.3.dylib 0x000000010d8c6c78 _glfwPlatformPollEvents + 140 4 libgnuradio-fosphor.3.7.0git.dylib 0x000000010d7be055 _ZN2gr7fosphor16base_sink_c_impl6workerEv + 119 5 libboost_thread-mt.dylib 0x0000000108c03ab5 _ZN5boost12_GLOBAL__N_112thread_proxyEPv + 53 6 libsystem_pthread.dylib 0x00007fffb07ae93b _pthread_body + 180 7 libsystem_pthread.dylib 0x00007fffb07ae887 _pthread_body + 0 8 libsystem_pthread.dylib 0x00007fffb07ae08d thread_start + 13 ) libc++abi.dylib: terminating with uncaught exception of type NSException
Change History (12)
comment:1 Changed 7 years ago by michaelld (Michael Dickens)
comment:2 Changed 7 years ago by roythompson (Roy Thompson)
MacBook Pro (Retina, 15-inch, Mid 2015) Processor 2.5 GHz Intel Core i7 Memory 16 GB 1600 MHz DDR3 Graphics AMD Radeon R9 M370X 2048 MB Intel Iris Pro 1536 MB
comment:3 Changed 7 years ago by michaelld (Michael Dickens)
I see the same error when using Fosphor GLFW sink (complex input). I don't get the issue when using the QT Fosphor sink.
Does the QT Fosphor sink work for you? Should be a drop-in replacement for the Fosphor GLFW sink.
comment:4 Changed 7 years ago by roythompson (Roy Thompson)
Yes, I can confirm that the QT Fosphor sink works.
comment:5 Changed 7 years ago by michaelld (Michael Dickens)
OK; great. Also, what does the following return for you:
port installed "glfw*"
comment:6 Changed 7 years ago by michaelld (Michael Dickens)
I've sent a query to the lead developers of GLFW and gr-fosphor asking them for help. Given how GNU Radio does threading, I don't see a way to make any specific block's thread the "main" one; that's just not how GR threading works! Hopefully you can use the Qt Fosphor Sink.
comment:7 Changed 7 years ago by roythompson (Roy Thompson)
Thanks, the QT sink should work for me. Here is the output of the installed command:
The following ports are currently installed: glfw @3.2.1_0+docs (active)
comment:8 Changed 7 years ago by michaelld (Michael Dickens)
OK thanks. That means the issue goes back at least to the current release. I use "glfw-devel", which has the most recent fixes in it & it still has this issue.
I'm glad you can use the Qt Fosphor sink, so at least this isn't a bottleneck for you.
comment:9 Changed 7 years ago by mf2k (Frank Schima)
Cc: | michaelld@… removed |
---|---|
Owner: | set to michaelld |
Status: | new → assigned |
comment:10 Changed 7 years ago by michaelld (Michael Dickens)
I forgot to followup from my discussion with the GLFW & gr-forphor lead devs. The consensus is to just not use GLFW fosphor on OSX because of this (artificial) constraint added by Apple. I will look into disabling this part of the gr-fosphor interface.
comment:11 Changed 7 years ago by michaelld (Michael Dickens)
comment:12 Changed 7 years ago by michaelld (Michael Dickens)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
What is your Mac hardware? You can find the info in "About This Mac" on the main (Apple logo) menu.