Forum: GNU Radio Thread AssertionError and Libc++abi.dylib on Mac Transmissions

Hey Folks,

I've installed the latest version of GNURadio (3.6.3) using MacPorts on 
a
fresh Macbook Pro running 10.8.2 using,

sudo port install gnuradio +full configure.compiler=llvm-gcc-4.2

Installation was flawless and I can receive using my USRP N210 just 
fine.
The problem comes when I try to transmit on my USRP. I can't pinpoint 
what's
causing it, but I get the following errors below when I try to transmit
through UHD. No changes to the included example (uhd_const_wave.grc) 
except
the IP address. Any help is appreciated, I've already tried several 
fresh
installs using CLANG and/or LLVM-GCC-4.2 and boost is at version 1.51.
Rebooting the USRP and/or the Mac has no effect.


Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM 
build
2336.11.00); Boost_105100; UHD_003.005.000-0-unknown

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Uthread[thread-per-block[1]: <gr_block gr uhd usrp sink (1)>]:
AssertionError: ::send(_sock_fd, (const char *)_mem, size(), 0) ==
ssize_t(size())
  in virtual void udp_zero_copy_asio_msb::release()
  at
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
.org_release_tarballs_ports_science_uhd/uhd/work/UHD-Mirror-release_003_005_
000/host/lib/transport/udp_zero_copy.cpp:115

S
>>> Done

and...

Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM 
build
2336.11.00); Boost_105100; UHD_003.005.000-0-unknown

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Ulibc++abi.dylib: terminate called without an active exception

>>> Done


Regards,

David

Hi David - I'm glad the MacPorts part isn't the issue :)  I wish I had 
an N210 to do testing on; heck, I wish I had even a (original; old) 
USRP1.  This issue seems like it might be better directed to the UHD 
discussion list < 
http://lists.ettus.com/mailman/listinfo/usrp-users... >.  I 
know many of the good folks over at Ettus read the GNU Radio list too -- 
but that seems like a more appropriate venue.  Wish I could help more; 
and, good luck! - MLD

Thanks, I'll shoot it over there and let you know what I get.

-David

Success!

UHD needed to be patched and recompiled, which removed both errors I was
having. Many thanks to Josh Blum and Tor Andre for helping me out!

Here's the link to the discussion so anyone else with this error can get
help:
http://lists.ettus.com/pipermail/usrp-users_lists....

Here's Josh's patch for udp_zerp_copy.cpp:
http://pastebin.com/YtMu0xj5

-David

I've updated the MacPorts ports for uhd (release) and uhd-devel with 
this patch < https://trac.macports.org/changeset/101668 >.  It will be 
live around 1 PM/ET/US. - MLD

> Success!
>
> I removed the MacPorts install, grabbed the latest version from the repository 
and made your suggested changes. Everything is running great now, as it seems my 
previous "Ulibc++abi.dylib: terminate called without an active exception" was also 
related to this.

On 14.01.2013, at 16:56, David Greene <djgreene730@gmail.com> wrote:

> through UHD. No changes to the included example (uhd_const_wave.grc) except
> the IP address. Any help is appreciated, I've already tried several fresh
> installs using CLANG and/or LLVM-GCC-4.2 and boost is at version 1.51.
> Rebooting the USRP and/or the Mac has no effect.
>


Hi David,

trying your trick on OS 10.8.1 gives me the error below when starting 
gnuradio-companion.
I've updated everything on macports before (which was a lot).

bash-3.2$ sudo port install gnuradio +full 
configure.compiler=llvm-gcc-4.2
Password:
--->  Computing dependencies for gnuradio
--->  Cleaning gnuradio
--->  Scanning binaries for linking errors: 100.0%
--->  No broken files found.
bash-3.2$ gnuradio-companion
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: 
GtkWarning: could not open display
  warnings.warn(str(e), _gtk.Warning)
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/grc/gui/Actions.py:30: 
GtkWarning: GdkKeymap *gdk_keymap_get_for_display(GdkDisplay *): 
assertion `GDK_IS_DISPLAY (display)' failed
  _keymap = gtk.gdk.keymap_get_default()
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/grc/gui/Colors.py:24: 
GtkWarning: GdkColormap *gdk_screen_get_system_colormap(GdkScreen *): 
assertion `GDK_IS_SCREEN (screen)' failed
  _COLORMAP = gtk.gdk.colormap_get_system() #create all of the colors
Traceback (most recent call last):
  File "/opt/local/bin/gnuradio-companion", line 58, in <module>
    from gnuradio.grc.python.Platform import Platform
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/grc/python/Platform.py", 
line 24, in <module>
    from FlowGraph import FlowGraph as _FlowGraph
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/grc/python/FlowGraph.py", 
line 22, in <module>
    from .. gui.FlowGraph import FlowGraph as _GUIFlowGraph
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/grc/gui/FlowGraph.py", 
line 22, in <module>
    import Colors
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/grc/gui/Colors.py", 
line 27, in <module>
    HIGHLIGHT_COLOR = get_color('#00FFFF')
  File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/grc/gui/Colors.py", 
line 25, in get_color
    def get_color(color_code): return _COLORMAP.alloc_color(color_code, 
True, True)
AttributeError: 'NoneType' object has no attribute 'alloc_color'

Hi Julian - I get the same error when I'm running using Apple's 
Terminal.app when the DISPLAY environment variable is not set (at all or 
correctly).  By default, GTK (which is what GRC uses for display) will 
interface to X11, which means you need Apple's X11.app, or MacOSForge's 
XQuartz.app, or (IIRC) MacPorts' xorg-server -- or use the Quartz 
variant of GTK (more below).

I use XQuartz < http://xquartz.macosforge.org/landing/ >; I do not 
recommend using Apple's X11.app mainly because it is rarely updated.  I 
have no experience with the xorg-server port, but I think it is the most 
up to date of the 3 X11 options.

Another option, which I've never tried but might work for you, is to 
install the port gtk2 using "+quartz -no_x11" which should bypass X11 
and go directly for Apple's Quartz display.

Hope this helps and good luck! - MLD

Hi Julian - The command to have MacPorts install GTK to use Quartz is 
"sudo port install gtk2 +no_x11 +quartz".  MacPorts will automatically 
deactivate the prior install of GTK2 and activate this one.  I've never 
tested this variant, so if you do do this, please post your results from 
trying to run GRC.  To get back the original (assuming it was installed 
with the defaults), you'd do "sudo port activate gtk2 +x11".

Note that GRC actually depends on PyGtk, which in turn depends on ATK, 
which depends on Cairo.  So, you'll probably want to install Cairo as 
"+quartz -x11".

Another way to do this, I think, is "sudo port --enforce-variants 
install gnuradio +grc +no_x11 +quartz -x11", which should go about 
installing replacements for those ports which can take the extra 
variants (e.g., cairo, gtk2).  You can also add your own variants to 
this list, e.g., "+gcc47" if that's your preferred gcc for FFTW and 
SciPy (and, others).

MacPorts can be both powerful and confusing, much like any reasonably 
complicated install system. - MLD