Solved clang++ program fails execution with Abort Trap

digifuzzy

digifuzzy

The fact that I can execute other programs built with clang, and that what I'm building has been built with clang++ on other systems, I think I may have broken my clang setup.

Program compiles successfully with clang++. However, any execution will fail with:
Code: 
Abort trap (core dumped)
.
devel/gdb backtrace gives...
Code: 
#0  0x0000000802105a1a in kill () from /lib/libc.so.7
#1  0x0000000802104149 in abort () from /lib/libc.so.7
#2  0x000000080198242d in __cxa_rethrow () from /lib/libcxxrt.so.1
#3  0x0000000000475ed3 in std::__1::basic_regex<char, std::__1::regex_traits<char> >::__parse_character_escape<std::__1::__wrap_iter<char const*> > (this=0x746b48, __first={__i = 0x8034170b3 "_]*?\"([\\S|\\s]*?)\","}, __last={__i = 0x8034170c5 ""},
  __str=0x7fffffffa3b8) at regex:4521
...(trimmed)
#13 0x000000000051ff65 in __cxx_global_var_init65 () at regex:2478
#14 0x0000000000523b07 in global constructors keyed to a () at main.cpp:2421
#15 0x0000000000523ba2 in __do_global_ctors_aux ()
#16 0x000000000040ad66 in _init ()
#17 0x00007fffffffde10 in ?? ()
#18 0x00000008007476bf in r_debug_state () from /libexec/ld-elf.so.1
#19 0x0000000800746d17 in __tls_get_addr () from /libexec/ld-elf.so.1
#20 0x0000000800745129 in .text () from /libexec/ld-elf.so.1
#21 0x0000000000000000 in ?? ()
ldd(1) gives
Code: 
  libcdt.so.5 => /usr/local/lib/graphviz/libcdt.so.5 (0x800960000)
   libcgraph.so.6 => /usr/local/lib/graphviz/libcgraph.so.6 (0x800b66000)
   libgvc.so.6 => /usr/local/lib/graphviz/libgvc.so.6 (0x800d7e000)
   libboost_system.so.1.55.0 => /usr/local/lib/libboost_system.so.1.55.0 (0x801019000)
   libboost_filesystem.so.1.55.0 => /usr/local/lib/libboost_filesystem.so.1.55.0 (0x80121c000)
   libboost_program_options.so.1.55.0 => /usr/local/lib/libboost_program_options.so.1.55.0 (0x801437000)
   libc++.so.1 => /usr/lib/libc++.so.1 (0x8016b0000)
   libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801970000)
   libm.so.5 => /lib/libm.so.5 (0x801b8c000)
   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801db4000)
   libc.so.7 => /lib/libc.so.7 (0x801fc2000)
   libthr.so.3 => /lib/libthr.so.3 (0x80236b000)
   libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x802590000)
   libxdot.so.4 => /usr/local/lib/graphviz/libxdot.so.4 (0x802799000)
   libpathplan.so.4 => /usr/local/lib/graphviz/libpathplan.so.4 (0x80299e000)
   libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x802ba6000)
   libz.so.6 => /lib/libz.so.6 (0x802dcd000)
I want to say that I've missed something either in invocation of the compiler or something broken in the toolchain for clang++. What am I missing, please?
 
Well this was a "dog's breakfast" to sort out!!! :mad::mad::eek::eek:

The "abort trap" error is attributed to lang/clang not liking a string in a regex statement. As soon as I commented out the offending line everything worked. Silly part is the exact same code compiled and executed successfully with clang on a linux box. o_O


Code: 
"text[\\s]*?=[\\s]*?[\\_]*?\"([\\S|\\s]*?)\","
This is the string being used for a regex statement. I have almost the exact same line being used somewhere else with one difference: "[\\_]*?"
The purpose of this statement was to look for
Code: 
text=_"something"
in a text file. So clang was balking at the search for the gettext marker.

This is similar to another bug I found in a Google search. I'll punt this over to the clang people.
 
junovitch said:
There was just a few patches that hit 10.1-STABLE for Clang issues. It doesn't look like this might have been one of them but take a look below.
Click to expand...
The links look like they talk about issues with get integer instructions. A little off, but thanks for passing along the information.

After comparing notes with the clang people on IRC, it was pointed out to me that the "_" literal character does not need to be escaped. And having escapes on a character that doesn't need it was making the program fail. Funny, I had tested the regex statements with online tools with problems. LFMF ;)

I was able to provide a test case for the fail. Hopefully, this will lead to something positive for clang. I've fixed my code now knowing how/why it was failing.
Let's call this one "workaround".
 
You must log in or register to reply here.
Back
Top