Compilation with poudriere gives bad binaries.

Hello, I've updated system to F14.1 and built packages from latest. First I got an unpleasant surprise, when ffmpeg4 crashed on any .flac file if built with llvm >13, and it seems nobody cared for a very long time, as I saw this a year ago. I've reported a bug, wrote to the maintainer, he isn't exactly blazing fast, but it's summer after all.

And now I have this...


Code:
[crypt /witch /mnt/2tb/torrents $ /usr/local/bin/rtorrent
Caught Illegal instruction, dumping stack:
0x2806b5 <_ZTVN7torrent14resource_errorE+0x3cd8d> at /usr/local/bin/rtorrent
0x82702d410 <pthread_sigmask+0x540> at /lib/libthr.so.3
0x82702c9cb <pthread_setschedparam+0x84b> at /lib/libthr.so.3
0x820feb2d3 <???> at ???
0x33b709 <_ZNK7torrent5Event9type_nameEv+0x7679> at /usr/local/bin/rtorrent
0x284258 <_ZN7torrent6ObjectC2ERKS0_+0x23a8> at /usr/local/bin/rtorrent
0x285b0f <_ZN7torrent6ObjectC2ERKS0_+0x3c5f> at /usr/local/bin/rtorrent
0x28b832 <_ZNK7torrent14internal_error4whatEv+0x1f12> at /usr/local/bin/rtorrent
0x337311 <_ZNK7torrent5Event9type_nameEv+0x3281> at /usr/local/bin/rtorrent
0x338e81 <_ZNK7torrent5Event9type_nameEv+0x4df1> at /usr/local/bin/rtorrent
0x340920 <_ZNK7torrent5Event9type_nameEv+0xc890> at /usr/local/bin/rtorrent
0x340c21 <_ZNK7torrent5Event9type_nameEv+0xcb91> at /usr/local/bin/rtorrent
0x27f3cf <_ZTVN7torrent14resource_errorE+0x3baa7> at /usr/local/bin/rtorrent
0x827771a6a <__libc_start1+0x12a> at /lib/libc.so.7
Abort trap

with debug

Code:
(gdb) run
Starting program: /usr/local/bin/rtorrent 
[New LWP 283753 of process 87102]

Thread 1 received signal SIGILL, Illegal instruction.
Privileged opcode.
0x00000000004793e2 in std::__1::__hash_table<std::__1::__hash_value_type<rpc::fixed_key_type<64ul>, rpc::object_storage_node>, std::__1::__unordered_map_hasher<rpc::fixed_key_type<64ul>, std::__1::__hash_value_type<rpc::fixed_key_type<64ul>, rpc::object_storage_node>, rpc::hash_fixed_key_type, std::__1::equal_to<rpc::fixed_key_type<64ul> >, true>, std::__1::__unordered_map_equal<rpc::fixed_key_type<64ul>, std::__1::__hash_value_type<rpc::fixed_key_type<64ul>, rpc::object_storage_node>, std::__1::equal_to<rpc::fixed_key_type<64ul> >, rpc::hash_fixed_key_type, true>, std::__1::allocator<std::__1::__hash_value_type<rpc::fixed_key_type<64ul>, rpc::object_storage_node> > >::end[abi:se180100](unsigned long) (this=0x8018191c0, __n=97) at /usr/include/c++/v1/__hash_table:932
932         _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(

Anybody knows what kind of stuff this is and where should I start to fix it? Looks like it crashed in a system component, didn't it? Why on Earth binary from the latest repo works and build system can't reproduce it...
 
The rtorrent thing we had before. It is a failing C++ assertion. Last time it was fixed with an upstream patch. I forgot the details, but if you search the forum for "rtorrent" you should get right at it.
 
What's in /etc/make.conf?
yes, right, i forgot

WITH_DEBUG_PORTS+=multimedia/mplayer WITH_DEBUG_PORTS+=net-p2p/rtorrent DEFAULT_VERSIONS+= pgsql=14 ssl=base python2=2.7 php=8.2 java=11 qt=5 DISABLE_LICENSES=yes OPTIONS_FILE_SET+=NLS OPTIONS_FILE_SET+=OPENMP OPTIONS_FILE_SET+=OPENSSL OPTIONS_FILE_SET+=DEVD OPTIONS_FILE_SET+=X265 OPTIONS_FILE_SET+=SNDIO OPTIONS_FILE_SET+=WEBP OPTIONS_FILE_SET+=LAME OPTIONS_FILE_UNSET+=UDEV OPTIONS_FILE_UNSET+=GSTREAMER OPTIONS_FILE_UNSET+=DBUS OPTIONS_FILE_UNSET+=AVAHI OPTIONS_FILE_UNSET+=KEYRING OPTIONS_FILE_UNSET+=PANGO OPTIONS_FILE_UNSET+=PANGOCAIRO OPTIONS_FILE_UNSET+=ZSH OPTIONS_FILE_UNSET+=EXAMPLES OPTIONS_FILE_UNSET+=PULSEAUDIO OPTIONS_FILE_UNSET+=PIPEWIRE OPTIONS_FILE_UNSET+=INFO
 
The rtorrent thing we had before. It is a failing C++ assertion. Last time it was fixed with an upstream patch. I forgot the details, but if you search the forum for "rtorrent" you should get right at it.
Yes, I see it. But as I'm not a programmer, I hardly understand what's assertion is. And I don't get why if it was fixed in Jun, I still see it two months later in the 'latest'. I also don't understand why the compiler with general flags produces the binary that don't work. Is this an LLVM bug?
 
By the way, it's surprisingly easy to refer to a specific reported bug; for a buzilla Problem Report just use its number, for example:
[PR]233706[/PR]
I will keep that in mind. But are there any practical reasons to include here what have to be solved there?
 
SIGILL / Illegal instruction strongly hints that poudriere is building a binary for a platform different (perhaps, slightly) from the actual hardware where you run the binary.
 
Yes, I see it. But as I'm not a programmer, I hardly understand what's assertion is. And I don't get why if it was fixed in Jun, I still see it two months later in the 'latest'. I also don't understand why the compiler with general flags produces the binary that don't work. Is this an LLVM bug?

No, it was a bug in rtorrent, but one that doesn't show up with gcc.
 
No, it was a bug in rtorrent, but one that doesn't show up with gcc.a
Well, fine... but I didn't build it with GCC! I built it with LLVM as it was in latest. More then that. If I take a binary package it works. So it has been built some other way, then port suggests. And that suggests that build system doesn't produce authentic binaries. We are talking about general amd64 arch here! So how come? It looks like you've answered only to a part of the questions, though if I understood how the project works it would help me to have adequate expectations.
 
Well, fine... but I didn't build it with GCC! I built it with LLVM as it was in latest. More then that. If I take a binary package it works. So it has been built some other way, then port suggests. And that suggests that build system doesn't produce authentic binaries. We are talking about general amd64 arch here! So how come? It looks like you've answered only to a part of the questions, though if I understood how the project works it would help me to have adequate expectations.

The rtorrent source problem did not show up in gcc, that is why the author didn't notice.

Can you run size(1) on the rtorrent binary and libtorrent? Both for your build and for the package version.

For all we know your port build is ahead of packages and broken again.

Also, according to your make.conf you turn on debug, which the package does not have. Maybe the assertion is turn off without debug (although it shouldn't).
 
> The rtorrent source problem did not show up in gcc, that is why the author didn't notice.

Ok. Some bug that nobody notice. With any version of compiler. That's weird.

> For all we know your port build is ahead of packages and broken again.

Is it possible, that I use port that is committed to port tree (latest) and is ahead of binary package that is in latest??? Now when you've mentioned I did

Code:
[root /witch /tmp/packages # file ./usr/local/bin/rtorrent
./usr/local/bin/rtorrent: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 (1400097), FreeBSD-style, stripped

It is build on F14.0 if this matters...

> Also, according to your make.conf you turn on debug, which the package does not have. Maybe the assertion is turn off without debug (although it shouldn't).

Man, I'm not psychic to turn debug before something breaks!) Of cause it doesn't matter.)

> Can you run size(1) on the rtorrent binary and libtorrent?

Here we go, I run only on binary as it's already unpacked and it is the only thing I've changed to get it work. Please, notice a relative path in the first case. It's built on my system.

Code:
[root /witch /tmp/packages # size ./usr/local/bin/rtorrent
     text   data    bss       dec        hex   filename
  5533513   4848   8280   5546641   0x54a291   ./usr/local/bin/rtorrent
[root /witch /tmp/packages # size /usr/local/bin/rtorrent
     text   data    bss       dec        hex   filename
  1327434   4864   6505   1338803   0x146db3   /usr/local/bin/rtorrent
 
> Can you run size(1) on the rtorrent binary and libtorrent?

Here we go, I run only on binary as it's already unpacked and it is the only thing I've changed to get it work. Please, notice a relative path in the first case.

[root /witch /tmp/packages # size ./usr/local/bin/rtorrent text data bss dec hex filename 1327434 4864 6505 1338803 0x146db3 ./usr/local/bin/rtorrent [root /witch /tmp/packages # size /usr/local/bin/rtorrent text data bss dec hex filename 1327434 4864 6505 1338803 0x146db3 /usr/local/bin/rtorrent

You need to do the same for libtorrent.so. That is where is bug is/was.
 
You need to do the same for libtorrent.so. That is where is bug is/was.
yes, sir!


This was built on my system.
Code:
[root /witch /tmp/packages # size ./usr/local/lib/libtorrent.so
    text    data    bss      dec       hex   filename
  968563   19624   3472   991659   0xf21ab   ./usr/local/lib/libtorrent.so
[root /witch /tmp/packages # size /usr/local/lib/libtorrent.so
    text    data    bss      dec       hex   filename
  968563   19624   3472   991659   0xf21ab   /usr/local/lib/libtorrent.so
[root /witch /tmp/packages # md5sum ./usr/local/lib/libtorrent.so
9ff716dd594c563cbd1e6c2c918cb5c2  ./usr/local/lib/libtorrent.so
[root /witch /tmp/packages # md5sum /usr/local/lib/libtorrent.so
9ff716dd594c563cbd1e6c2c918cb5c2  /usr/local/lib/libtorrent.so

Or should I download libtorrent from official packages and check it too?
 
Seems like with rtorrent from package and self-built libtorrent, the program starts but crashes later. And when I built both the program didn't start at all. Possibly not one bug...
 
Code:
[root /witch /tmp/packages # size ./usr/local/bin/rtorrent
     text   data    bss       dec        hex   filename
  5533513   4848   8280   5546641   0x54a291   ./usr/local/bin/rtorrent
[root /witch /tmp/packages # size /usr/local/bin/rtorrent
     text   data    bss       dec        hex   filename
  1327434   4864   6505   1338803   0x146db3   /usr/local/bin/rtorrent

Why is the local one so much bigger in text (code)?
 
I don't know. May be because of the debug?

The actual debug information does not count toward "text" in size(1).

However, compiling in debug mode might have turned on (lots of) assertions. That would also explain why the big binary hits an assertion (throwing illegal instruction) and the small one does not.
 
The actual debug information does not count toward "text" in size(1).

However, compiling in debug mode might have turned on (lots of) assertions. That would also explain why the big binary hits an assertion (throwing illegal instruction) and the small one does not.
Here is without debug. Text size is ok.

Code:
[crypt /witch /tmp/packages $ usr/local/bin/rtorrent
Caught Illegal instruction, dumping stack:
0x2807f0 <_ZTVN7torrent14resource_errorE+0x3c428> at /tmp/packages/usr/local/bin/rtorrent
0x828227410 <pthread_sigmask+0x540> at /lib/libthr.so.3
0x8282269cb <pthread_setschedparam+0x84b> at /lib/libthr.so.3
0x8214752d3 <???> at ???
0x3395f2 <_ZNK7torrent5Event9type_nameEv+0x7362> at /tmp/packages/usr/local/bin/rtorrent
0x2842e2 <_ZN7torrent6ObjectC2ERKS0_+0x2312> at /tmp/packages/usr/local/bin/rtorrent
0x285ba8 <_ZN7torrent6ObjectC2ERKS0_+0x3bd8> at /tmp/packages/usr/local/bin/rtorrent
0x28b822 <_ZNK7torrent14internal_error4whatEv+0x1f62> at /tmp/packages/usr/local/bin/rtorrent
0x335502 <_ZNK7torrent5Event9type_nameEv+0x3272> at /tmp/packages/usr/local/bin/rtorrent
0x337103 <_ZNK7torrent5Event9type_nameEv+0x4e73> at /tmp/packages/usr/local/bin/rtorrent
0x33cd7e <_ZNK7torrent5Event9type_nameEv+0xaaee> at /tmp/packages/usr/local/bin/rtorrent
0x33d083 <_ZNK7torrent5Event9type_nameEv+0xadf3> at /tmp/packages/usr/local/bin/rtorrent
0x27f55f <_ZTVN7torrent14resource_errorE+0x3b197> at /tmp/packages/usr/local/bin/rtorrent
0x828e2da6a <__libc_start1+0x12a> at /lib/libc.so.7
Abort trap
[crypt /witch /tmp/packages $ size usr/local/bin/rtorrent
     text   data    bss       dec        hex   filename
  1339687   4776   7800   1352263   0x14a247   usr/local/bin/rtorrent
[crypt /witch /tmp/packages $ file usr/local/bin/rtorrent
usr/local/bin/rtorrent: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.1, FreeBSD-style, stripped
[CODE]
 
That would also explain why the big binary hits an assertion (throwing illegal instruction) and the small one does not.
Btw, when you say "assertion", is it about https://en.wikipedia.org/wiki/Assertion_(software_development) ? I'm still trying to understand what this error is about.

Code:
An assertion statement specifies a condition that you expect to be true at a point in your program. If that condition is not true, the assertion fails, execution of your program is interrupted, and the Assertion Failed dialog box appears.

Don't understand, how condition error is related to wrong CPU instructions. Maybe you have some link for clarification.
 
No, it was a bug in rtorrent, but one that doesn't show up with gcc.
The question is, if GCC produced working code. Because at this point a very correct LLVM compiler doesn't. And the hell strange thing goes with FreeBSD repo, which contains some random builds with some random conditions.

Also at this point the package doesn't build with GCC on FreeBSD.
Code:
command_ip.cc:(.text.unlikely+0x9c6): undefined reference to `torrent::internal_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: command_ip.cc:(.text.unlikely+0xcc6): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: ui/libsub_ui.a(element_log_complete.o): in function `ui::ElementLogComplete::ElementLogComplete(torrent::log_buffer*)':
element_log_complete.cc:(.text+0x1df): undefined reference to `torrent::signal_bitfield::add_signal(std::function<void ()>)'
/usr/local/bin/ld: core/libsub_core.a(dht_manager.o): in function `core::DhtManager::save_dht_cache()':
dht_manager.cc:(.text+0x103d): undefined reference to `torrent::operator<<(std::ostream&, torrent::Object const&)'
/usr/local/bin/ld: core/libsub_core.a(dht_manager.o): in function `core::DhtManager::load_dht_cache()':
dht_manager.cc:(.text+0x2a12): undefined reference to `torrent::operator>>(std::istream&, torrent::Object&)'
/usr/local/bin/ld: core/libsub_core.a(download.o): in function `core::Download::set_root_directory(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
download.cc:(.text+0xd24): undefined reference to `torrent::FileList::set_root_dir(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: core/libsub_core.a(download_factory.o): in function `core::DownloadFactory::log_created(core::Download*, torrent::Object*)':
download_factory.cc:(.text+0x16f5): undefined reference to `torrent::hash_string_to_hex_str[abi:cxx11](torrent::HashString const&)'
/usr/local/bin/ld: core/libsub_core.a(download_factory.o): in function `core::download_factory_add_stream(torrent::Object*, char const*, char const*) [clone .isra.0]':
download_factory.cc:(.text+0x2519): undefined reference to `torrent::operator>>(std::istream&, torrent::Object&)'
/usr/local/bin/ld: core/libsub_core.a(download_factory.o): in function `core::DownloadFactory::initialize_rtorrent(core::Download*, torrent::Object*)':
download_factory.cc:(.text+0x2b2d): undefined reference to `torrent::Object::insert_preserve_type(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, torrent::Object&)'
/usr/local/bin/ld: download_factory.cc:(.text+0x2b9d): undefined reference to `torrent::Object::insert_preserve_type(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, torrent::Object&)'
/usr/local/bin/ld: download_factory.cc:(.text+0x2c40): undefined reference to `torrent::Object::insert_preserve_type(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, torrent::Object&)'
/usr/local/bin/ld: download_factory.cc:(.text+0x2ce8): undefined reference to `torrent::Object::insert_preserve_type(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, torrent::Object&)'
/usr/local/bin/ld: download_factory.cc:(.text+0x2d6b): undefined reference to `torrent::Object::insert_preserve_type(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, torrent::Object&)'
/usr/local/bin/ld: core/libsub_core.a(download_factory.o):download_factory.cc:(.text+0x3301): more undefined references to `torrent::Object::insert_preserve_type(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, torrent::Object&)' follow
/usr/local/bin/ld: core/libsub_core.a(download_factory.o): in function `core::DownloadFactory::receive_success()':
download_factory.cc:(.text+0x544d): undefined reference to `torrent::file_split_all(torrent::FileList*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: core/libsub_core.a(download_factory.o): in function `core::DownloadFactory::receive_load()':
download_factory.cc:(.text+0x66ca): undefined reference to `torrent::operator>>(std::istream&, torrent::Object&)'
/usr/local/bin/ld: core/libsub_core.a(download_list.o): in function `core::DownloadList::create(std::istream*, bool)':
download_list.cc:(.text+0x82b): undefined reference to `torrent::operator>>(std::istream&, torrent::Object&)'
/usr/local/bin/ld: core/libsub_core.a(download_list.o): in function `core::DownloadList::process_meta_download(core::Download*)':
download_list.cc:(.text+0x4b80): undefined reference to `torrent::operator>>(std::istream&, torrent::Object&)'
/usr/local/bin/ld: core/libsub_core.a(download_list.o): in function `core::DownloadList::insert(core::Download*) [clone .cold]':
download_list.cc:(.text.unlikely+0x2ff): undefined reference to `torrent::internal_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: core/libsub_core.a(download_store.o): in function `core::DownloadStore::write_bencode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, torrent::Object const&, unsigned int)':
download_store.cc:(.text+0x1c34): undefined reference to `torrent::object_write_bencode(std::ostream*, torrent::Object const*, unsigned int)'
/usr/local/bin/ld: download_store.cc:(.text+0x1cb8): undefined reference to `torrent::operator>>(std::istream&, torrent::Object&)'
/usr/local/bin/ld: core/libsub_core.a(download_store.o): in function `core::DownloadStore::get_formated_entries() [clone .cold]':
download_store.cc:(.text.unlikely+0x639): undefined reference to `torrent::storage_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: core/libsub_core.a(manager.o): in function `core::Manager::try_create_download_from_meta_download(torrent::Object*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
manager.cc:(.text+0x3fdb): undefined reference to `torrent::operator<<(std::ostream&, torrent::Object const&)'
/usr/local/bin/ld: core/libsub_core.a(poll_manager.o): in function `core::create_poll() [clone .cold]':
poll_manager.cc:(.text.unlikely+0x94): undefined reference to `torrent::internal_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: core/libsub_core.a(view.o): in function `core::view_downloads_filter::evalCmd(torrent::Object const&, core::Download*) const [clone .isra.0] [clone .cold]':
view.cc:(.text.unlikely+0x4c): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: core/libsub_core.a(view.o): in function `core::view_downloads_compare::operator()(core::Download*, core::Download*) const':
view.cc:(.text._ZNK4core22view_downloads_compareclEPNS_8DownloadES2_[_ZNK4core22view_downloads_compareclEPNS_8DownloadES2_]+0x249): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: view.cc:(.text._ZNK4core22view_downloads_compareclEPNS_8DownloadES2_[_ZNK4core22view_downloads_compareclEPNS_8DownloadES2_]+0x2be): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: view.cc:(.text._ZNK4core22view_downloads_compareclEPNS_8DownloadES2_[_ZNK4core22view_downloads_compareclEPNS_8DownloadES2_]+0x351): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: view.cc:(.text._ZNK4core22view_downloads_compareclEPNS_8DownloadES2_[_ZNK4core22view_downloads_compareclEPNS_8DownloadES2_]+0x3d3): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: core/libsub_core.a(view_manager.o):view_manager.cc:(.text.unlikely+0xde): more undefined references to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' follow
/usr/local/bin/ld: core/libsub_core.a(curl_stack.o): in function `core::CurlStack::transfer_done(void*, char const*)':
curl_stack.cc:(.text+0x788): undefined reference to `torrent::Http::trigger_failed(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: display/libsub_display.a(canvas.o): in function `display::Canvas::Canvas(int, int, int, int) [clone .cold]':
canvas.cc:(.text.unlikely+0xf3): undefined reference to `torrent::internal_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: display/libsub_display.a(canvas.o): in function `display::Canvas::initialize() [clone .cold]':
canvas.cc:(.text.unlikely+0x1d1): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: display/libsub_display.a(window_download_list.o): in function `display::WindowDownloadList::redraw() [clone .cold]':
window_download_list.cc:(.text.unlikely+0x101): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: display/libsub_display.a(window_log.o): in function `display::WindowLog::WindowLog(torrent::log_buffer*)':
window_log.cc:(.text+0x2f4): undefined reference to `torrent::signal_bitfield::add_signal(std::function<void ()>)'
/usr/local/bin/ld: rpc/libsub_rpc.a(command_map.o): in function `rpc::CommandMap::insert(char const*, int, char const*, char const*) [clone .cold]':
command_map.cc:(.text.unlikely+0x1e5): undefined reference to `torrent::internal_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: rpc/libsub_rpc.a(command_map.o): in function `rpc::CommandMap::erase(std::_Rb_tree_iterator<std::pair<char const* const, rpc::command_map_data_type> >) [clone .cold]':
command_map.cc:(.text.unlikely+0x2e3): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: rpc/libsub_rpc.a(exec_file.o): in function `rpc::ExecFile::execute(char const*, char* const*, int) [clone .cold]':
exec_file.cc:(.text.unlikely+0xa3): undefined reference to `torrent::internal_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: rpc/libsub_rpc.a(parse_commands.o): in function `rpc::parse_command(rpc::rt_triple<int, void*, void*>, char const*, char const*) [clone .cold]':
parse_commands.cc:(.text.unlikely+0x138): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: rpc/libsub_rpc.a(parse_commands.o): in function `rpc::parse_command_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) [clone .cold]':
parse_commands.cc:(.text.unlikely+0x643): undefined reference to `torrent::internal_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: rpc/libsub_rpc.a(scgi.o): in function `torrent::resource_error::resource_error(char const*)':
scgi.cc:(.text._ZN7torrent14resource_errorC2EPKc[_ZN7torrent14resource_errorC5EPKc]+0x68): undefined reference to `torrent::resource_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: rpc/libsub_rpc.a(scgi.o): in function `torrent::resource_error::resource_error(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
scgi.cc:(.text._ZN7torrent14resource_errorC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN7torrent14resource_errorC5ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x26): undefined reference to `torrent::resource_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/bin/ld: utils/libsub_utils.a(directory.o): in function `utils::Directory::update(int) [clone .cold]':
directory.cc:(.text.unlikely+0x74): undefined reference to `torrent::input_error::initialize(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
 
Btw, when you say "assertion", is it about https://en.wikipedia.org/wiki/Assertion_(software_development) ? I'm still trying to understand what this error is about.

Code:
An assertion statement specifies a condition that you expect to be true at a point in your program. If that condition is not true, the assertion fails, execution of your program is interrupted, and the Assertion Failed dialog box appears.

Don't understand, how condition error is related to wrong CPU instructions. Maybe you have some link for clarification.

Throwing an "illegal instruction" is a choice made by the libc++ people. The illegal instruction is artificially inserted into the code path for the failing condition.

It has nothing to do with e.g. mistaking which instruction set is supported by the current CPU.
 
Throwing an "illegal instruction" is a choice made by the libc++ people. The illegal instruction is artificially inserted into the code path for the failing condition.
Are you sure about that?
Because that's weird.

Traditionally, abort(3) is used by assertions resulting in SIGABRT .
I've also seen SIGTRAP (generated by int3 instruction on x86) used in the code that shouldn't be executed (e.g., because of undefined behavior).

This is the first time I hear about SIGILL used for diagnostic purposes.
 
Found this https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html :
-fsanitize-trap=...: execute a trap instruction (doesn’t require UBSan run-time support). If the signal is not caught, the program will typically terminate due to a SIGILL or SIGTRAP signal.
And the low level instruction seems to be ud2.
So, it should be easy to check in the core dump (or the executable itself) whether the instruction is diagnostic or just unsupported.
 
Back
Top