I've been using a command line program (installed via package manager) that was working fine until I used vim to inadvertently insert a null byte (^@) in one of the program's data files when doing search and replace using the vim :s(substitute) command. Since then the program won't run instead I get this error:

/usr/include/c++/9/bits/basic_string.h:1048: std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator[](std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference = const char&; std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]: Assertion '__pos <= size()' failed.
Aborted (core dumped)

gnome-abrt shows that the reason for the error is:

task killed by SIGABRT

Specifically SIGABRT 6

  • In Linux, what does inserting a null byte in a text file that is read by an executable do? The way the null byte was inserted into the program's data file is analogous to if I insert a null byte in a git commit message and that somehow breaks git.

  • Could the null byte be causing the program to crash when it reads that text file or is there a different reason?


The man page signal(7) says:

Signal     Value     Action   Comment
SIGABRT       6       Core    Abort signal from abort(3)

And abort(3):

abort - cause abnormal process termination

The  abort()  first  unblocks the SIGABRT signal, and then raises that
signal for the calling process (as though raise(3) was called).  This
results in the abnormal termination of the process

So, dying by SIGABRT most likely happens when the program itself decides to, well, abort. It might have some sanity check for the data, and aborts if the data is invalid.

The assert() macro also calls abort(), and as it happens your error message has this bit:

std::__cxx11::basic_string...: Assertion '__pos <= size()' failed.

which seems to indicate that the invalid value gets used somewhere within the C++ library, and there's a check for an impossible situation, which triggers from the invalid data.

  • assert() is not a function. Cannot be a function. Functions in C only take values, not expressions as arguments. – mosvy Jul 9 at 18:12
  • @mosvy, yeah, it's probably a macro. A function implementation would have to choose a type of value to expect as argument. – ilkkachu Jul 9 at 18:16
  • It's very certainly a macro; assert() is required by the C and C++ standards to be a macro. And a theoretical implementation of it as a function would be horrendously expensive -- the complete source code and parsed syntax tree would have to be accessible at run time for it to work. – mosvy Jul 9 at 18:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.