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 :slight_smile: 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_lists.ettus.com >. 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 B. 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.ettus.com/2013-January/006017.html

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 G. [email protected] 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 *): assertionGDK_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
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
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
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
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
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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs