Bug 213031 - lang/ruby22: Segmentation fault during compilation of port
Summary: lang/ruby22: Segmentation fault during compilation of port
Status: Closed Unable to Reproduce
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ruby (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-27 20:48 UTC by elofu17
Modified: 2016-12-07 19:56 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (ruby)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description elofu17 2016-09-27 20:48:19 UTC
I get a reproduceable error while compiling the ruby-2.2.5,1 port for FreeBSD 9.3 amd64.


Story:
Today I installed a new freebsd-builder machine for building ports using poudriere. Host OS on the builder is FreeBSD 10.3 amd64.

On this machine I let poudriere create four build jails:
10.3 amd64
10.1 amd64
9.3 amd64
9.3 i386

In all four jails I compile the same list of ports, where lang/ruby22 is one of them.

The port compiles just fine in three jails, but in the 9.3 amd64 jail, I repeatedly get a "Segmentation fault (core dumped)".

Syslog message:
2016-09-27 21:55:24 +02:00 freebsd-builder kernel: pid 71467 (conftest), uid 0: exited on signal 11 (core dumped)

Here's a snippet from the build logfile:
/usr/local/poudriere/data/logs/bulk/93amd64-default/2016-09-27_21h39m31s/logs/ruby-2.2.5,1.log
...
...
checking for timezone... yes
checking whether timezone requires zero arguments... no
checking for negative time_t for gmtime(3)... yes
checking for localtime(3) overflow correctly... no
checking whether right shift preserve sign bit... yes
checking whether _SC_CLK_TCK is supported... yes
checking stack growing direction on amd64... -1
checking for pthread_kill in -lpthread... yes
checking for pthread_np.h... yes
checking whether pthread_t is scalar type... yes
checking for sched_yield... (cached) yes
checking for pthread_attr_setinheritsched... yes
checking for pthread_attr_get_np... yes
checking for pthread_attr_getstack... yes
checking for pthread_get_stackaddr_np... no
checking for pthread_get_stacksize_np... no
checking for thr_stksegment... no
checking for pthread_stackseg_np... no
checking for pthread_getthrds_np... no
checking for pthread_cond_init... (cached) yes
checking for pthread_condattr_setclock... yes
checking for pthread_condattr_init... yes
checking for pthread_sigmask... yes
checking for pthread_setname_np... no
checking for pthread_getattr_np... no
checking for pthread_attr_init... yes
checking if mcontext_t is a pointer... no
checking for getcontext... yes
checking for setcontext... yes
checking if fork works with pthread... yes
checking whether ELF binaries are produced... yes
checking for elf.h... (cached) yes
checking elf_abi.h usability... no
checking elf_abi.h presence... no
checking for elf_abi.h... no
checking whether OS depend dynamic link works... yes
checking for procstat_open_sysctl in -lprocstat... yes
checking for procstat_getvmmap... yes
checking execinfo.h usability... yes
checking execinfo.h presence... yes
checking for execinfo.h... yes
checking for backtrace in -lexecinfo... yes
checking for unw_backtrace in -lunwind... no
checking for backtrace... yes
checking for broken backtrace... Segmentation fault (core dumped)   <----------
yes
checking valgrind/memcheck.h usability... no
checking valgrind/memcheck.h presence... no
checking for valgrind/memcheck.h... no
checking for strip... strip
checking for __builtin_setjmp... yes with cast ()
checking for setjmp type... __builtin_setjmp
checking for prefix of external symbols... NONE
checking pthread.h usability... yes
...
...
Comment 1 elofu17 2016-09-28 08:55:06 UTC
The port is compiled.

The problem is that "kernel: pid 73849 (conftest), uid 0: exited on signal 11 (core dumped)" is syslogged.
It is sent to the central logserver, where the security team see it and create Jira tickets, asking me what's happening.

Since 9.3 is soon EOL I don't expect any action.

This is just an informational report, in case the same thing happen again on other versions/architectures.
Comment 2 Steve Wills freebsd_committer freebsd_triage 2016-12-07 19:56:20 UTC
Unable to reproduce the sig 11, but since it's not causing an issue and as you say 9.3 EOL is soon, not going to research further. Closing.