Compilation with poudriere gives bad binaries.

Andriy said:
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.
Click to expand...

Yes, I'm sure. It is for the C++ libraries only. Sigabort is already used for exceptions, so they had to use something different.

The easiest way to reproduce is to make a C++ string with size 0 and then read s[0].
 
cracauer@ said:
Yes, I'm sure. It is for the C++ libraries only. Sigabort is already used for exceptions, so they had to use something different.

The easiest way to reproduce is to make a C++ string with size 0 and then read s[0].
Click to expand...
This is another backtrace when both rtorrent and libtorrent are from binary packages

Code: 
(gdb) bt
#0  0x00000008008bc62a in _sendto () from /lib/libc.so.7
#1  0x00000008005f39fd in ?? () from /lib/libthr.so.3
#2  0x0000000800554a57 in ?? () from /usr/local/lib/libtorrent.so.21
#3  0x0000000800563219 in ?? () from /usr/local/lib/libtorrent.so.21
#4  0x00000008004f495e in torrent::PollKQueue::perform() () from /usr/local/lib/libtorrent.so.21
#5  0x00000008004f4ad9 in torrent::PollKQueue::do_poll(long, int) () from /usr/local/lib/libtorrent.so.21
#6  0x0000000800528e09 in torrent::thread_base::event_loop(torrent::thread_base*) () from /usr/local/lib/libtorrent.so.21
#7  0x0000000000281808 in ?? ()
#8  0x0000000800808a6a in __libc_start1 () from /lib/libc.so.7
#9  0x000000000027f3b0 in ?? ()
(gdb)
 
crypt47 said:
This is another backtrace when both rtorrent and libtorrent are from binary packages

Code: 
(gdb) bt
#0  0x00000008008bc62a in _sendto () from /lib/libc.so.7
#1  0x00000008005f39fd in ?? () from /lib/libthr.so.3
#2  0x0000000800554a57 in ?? () from /usr/local/lib/libtorrent.so.21
#3  0x0000000800563219 in ?? () from /usr/local/lib/libtorrent.so.21
#4  0x00000008004f495e in torrent::PollKQueue::perform() () from /usr/local/lib/libtorrent.so.21
#5  0x00000008004f4ad9 in torrent::PollKQueue::do_poll(long, int) () from /usr/local/lib/libtorrent.so.21
#6  0x0000000800528e09 in torrent::thread_base::event_loop(torrent::thread_base*) () from /usr/local/lib/libtorrent.so.21
#7  0x0000000000281808 in ?? ()
#8  0x0000000800808a6a in __libc_start1 () from /lib/libc.so.7
#9  0x000000000027f3b0 in ?? ()
(gdb)
Click to expand...

Backtrace for what condition?
 
crypt47 said:
When program crashes after some time... If build it, it will not run. Otherwise from binary packages it runs but fails after some time.
Click to expand...

Yeah but what is it doing? SIGILL? Segmentation fault?

You posted the backtrace omitting that info.
 
cracauer@ said:
Yeah but what is it doing? SIGILL? Segmentation fault?

You posted the backtrace omitting that info.
Click to expand...
i see, it's
Code: 
hread 1 "rtorrent main" received signal SIGPIPE, Broken pipe.
                                                             Sent by kernel.
                                                                            0x00000008008bc62a in _sendto () from /lib/libc.so.7
 
It might be totally unrelated but I had this error with the Transmission bittorrent client, 2 or 3 weeks ago, after about 30 seconds running, and it was because of a bug in curl:
forums.freebsd.org

Transmission keeps closing

I've installed transmission a number of times and this is the first time it has happened. When I start the application, it just closes itself after a couple of minutes. I don't know what is causing it. I removed the application and reinstalled it again. Nothing has changed. Any ideas?
forums.freebsd.org forums.freebsd.org
 
cracauer@ said:
Yeah but what is it doing? SIGILL? Segmentation fault?

You posted the backtrace omitting that info.
Click to expand...
As far as I understand, the same version of rtorrent worked on previous release. If I use binary from F13.2, it crashes all the same. I guess something's wrong with FreeBSD release itself.
 
cracauer@ said:
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).
Click to expand...
Assert statements are removed when NDEBUG is defined, but it's been years since I did that. Please someone check that (I'm currently on my phone...)
cracauer@ said:
The easiest way to reproduce is to make a C++ string with size 0 and then read s[0].
Click to expand...
Or "assert(false);"
And -O0, or it will be optimized into nothingness.
 
I just built a default rtorrent on -current with the upstream patch against SIGILL and it ran overnight with no problems.

I have never seen the pipe error.
 
cracauer@ said:
I just built a default rtorrent on -current with the upstream patch against SIGILL and it ran overnight with no problems.

I have never seen the pipe error.
Click to expand...
How do I get the SIGIL patch? The SIGPIPE problem is kinda weird. I get it with any binary, even on that was working in F13.2. So the problem seems in system itself. But I don't know on what conditions _sendto in libc gives me SIGPIPE. I checked checksum on libc, the update seems to be ok. Can't understand why after updating my system I got a broken application.
 
crypt47 said:
How can I get the SIGIL patch? The SIGPIPE problem is kinda weird. I get it with any binary, even on that was working in F13.2. So the problem seems in system itself. But I don't know on what conditions _sendto in libc gives me SIGPIPE. I checked checksum on libc, the update seems to be ok. Can't understand why after updating my system I got a broken application.
Click to expand...

The patch that fixes the SIGILL is here:
github.com

Use regular iterators intead of bucket-local ones · kannibalox/rtorrent@30addc1

Trying to manually predict which bucket a hashed key will land in does not appear to be well-defined behavior. Fixes #1285
github.com github.com
also attached.

Can you list the OS versions where you did see SIGPIPE?
 

Attachments

  • diff.txt
    8.1 KB · Views: 19
cracauer@ said:
The patch that fixes the SIGILL is here:
github.com

Use regular iterators intead of bucket-local ones · kannibalox/rtorrent@30addc1

Trying to manually predict which bucket a hashed key will land in does not appear to be well-defined behavior. Fixes #1285
github.com github.com
also attached.

Can you list the OS versions where you did see SIGPIPE?
Click to expand...
thanks. why this patch failed to apply? is it for rtorrent or libtorrent?

Code: 
===>  Patching for rtorrent-0.9.8
===>  Applying FreeBSD patches for rtorrent-0.9.8 from /usr/ports/net-p2p/rtorrent/files
No file to patch.  Skipping...
2 out of 2 hunks ignored--saving rejects to a/src/command_dynamic.cc.rej
Can't create a/src/command_dynamic.cc.rej, output is in /tmp/patchraWEcUEL8nT: No such file or directory
No file to patch.  Skipping...
5 out of 5 hunks ignored--saving rejects to a/src/rpc/object_storage.cc.rej
Can't create a/src/rpc/object_storage.cc.rej, output is in /tmp/patchraWEcUEL8nT: No such file or directory
No file to patch.  Skipping...
2 out of 2 hunks ignored--saving rejects to a/src/rpc/object_storage.h.rej
Can't create a/src/rpc/object_storage.h.rej, output is in /tmp/patchraWEcUEL8nT: No such file or directory
===>  FAILED Applying FreeBSD patch-sigill.cc
===> FAILED to apply cleanly FreeBSD patch(es)  patch-sigill.cc
*** Error code 1


here are versions

Code: 
[root /witch /home/crypt # freebsd-version -uk
14.1-RELEASE-p3
14.1-RELEASE-p3
 
You must log in or register to reply here.
Back
Top