Need some help debugging c++ code for 10.0

Shane Ambler FreeBSD at ShaneWare.Biz
Mon Oct 7 13:42:48 UTC 2013

Hi there, I am the port maintainer for opencolorio, openimageio and 
openshadinglanguage. These build and run on 9.2 with clang 3.3 but I 
have an issue on 10.0. I don't have much programming experience and even 
less with c++ which all 3 use.

After ocio and oiio are installed building osl generates oslc (the osl 
script compiler) and then runs it to pre-compile the included scripts. 
This step fails on 10.0

I am fairly sure that the issue is within the ustring class - full code 
can be viewed at with src/include/ustring.h 
having some info about the class.

The following is from src/libutil/ustring.cpp for ustrings constructor

#if defined(__GNUC__)
// We don't want the internal 'string str' to redundantly store the
// chars, along with our own allocation.  So we use our knowledge of
// the internal structure of gcc strings to make it point to our chars!
// Note that we've carefully structured the TableRep fields so they
// mimic a GCC basic_string::_Rep.
// It turns out that the first field of a gcc std::string is a
// pointer to the characters within the basic_string::_Rep.  We
// merely redirect that pointer, though for std::string to function
// properly, the chars must be preceeded immediately in memory by
// the rest of basic_string::_Rep, consisting of length, capacity
// and refcount fields.  And we have designed our TableRep to do
// just that!  So now we redirect the std::string's pointer to our
// own characters and its mocked-up _Rep.
// See /usr/include/c++/VERSION/bits/basic_string.h for the details
// of gcc's std::string implementation.

*(const char **)&str = c_str();
DASSERT (str.c_str() == c_str());
// Not gcc -- just assign the internal string.  This will result in
// double allocation for the chars.  If you care about that, do
// something special for your platform, much like we did for gcc
// above.  (Windows users, I'm talking to you.)
str = s;

When the osl build starts to precompile the bundled osl scripts oslc 
triggers the DASSERT (which is line 137) shown above. If I adjust the 
#if (and the matching destructor) so the non-gcc fallback is used, osl 
still fails just without the assert message.

Running the osl compile step in gdb I get the following backtrace --

failed assertion 'str.c_str() == c_str()'

Program received signal SIGABRT, Aborted.
[Switching to Thread 819406400 (LWP 100230/oslc)]
0x000000080344998a in thr_kill () from /lib/
(gdb) bt
#0  0x000000080344998a in thr_kill () from /lib/
#1  0x0000000803518259 in abort () from /lib/
#2  0x000000080196d120 in TableRep (this=0x81943c3d0, s=0x801bb50b8 
"resolution", len=10)
#3  0x000000080196d607 in OpenImageIO::v1_2::ustring::make_unique 
(str=0x801bb50b8 "resolution")
#4  0x000000080110118f in ustring (this=0x801f21e20, str=0x801bb50b8 
"resolution") at ustring.h:166
#5  0x000000080110114d in ustring (this=0x801f21e20, str=0x801bb50b8 
"resolution") at ustring.h:167
#6  0x00000008019ae35b in __cxx_global_var_init16 ()
#7  0x00000008019c8a39 in global constructors keyed to a ()
#8  0x0000000801ba83b2 in __do_global_ctors_aux () from 
#9  0x00000008015a7d0e in _init () from /usr/local/lib/
#10 0x00007fffffffccc0 in ?? ()
#11 0x0000000800616701 in objlist_call_init () from /libexec/
#12 0x0000000800615c97 in _rtld () from /libexec/
#13 0x0000000800614089 in .text () from /libexec/
#14 0x0000000000000000 in ?? ()

More information about the freebsd-ports mailing list