gmake: Entering directory '/wrkdirs/usr/ports/lang/erlang-runtime21/work/otp_src_21.2/erts/emulator'
if utils/gen_git_version i386-portbld-freebsd13.0/gen_git_version.mk; then touch beam/erl_bif_info.c; fi
echo " PROFILE beam.prof.smp"
rm -f obj/i386-portbld-freebsd13.0/opt/smp/erl*.profraw
set -e; LLVM_PROFILE_FILE="obj/i386-portbld-freebsd13.0/opt/smp/erlc-%m.profraw" \
ERL_FLAGS="-emu_type prof +S 1" erlc -W -DPGO \
-o obj/i386-portbld-freebsd13.0/opt/smp test/estone_SUITE.erl > obj/i386-portbld-freebsd13.0/opt/smp/PROFILE_LOG
dlsym: Resource temporarily unavailable
gmake: *** [i386-portbld-freebsd13.0/Makefile:734: obj/i386-portbld-freebsd13.0/opt/smp/PROFILE] Abort trap (core dumped)
gmake: Leaving directory '/wrkdirs/usr/ports/lang/erlang-runtime21/work/otp_src_21.2/erts/emulator'
Maintainer informed via mail
jilles points out on IRC that reporting errno after dlsym failure (as this is presumably doing) is invalid; the string returned by dlerror should be printed instead. The EAGAIN text likely has no direct relationship with the actual issue.
I've added extra debugging and found the problematic dlsym is in do_init in otp_src_21.2/erts/emulator/hipe/hipe_x86_signal.c.
This calls dlysym as follows:
#define NEXT_SIGACTION "sigaction"
next_sigaction = dlsym(RTLD_NEXT, NEXT_SIGACTION);
I added a printf with the dlerror string. This found the error to be:
"Cannot determine caller's shared object"
That error is from rtld when obj_from_addr returns NULL. Looking with a debugger this seems to be because the map size is 0. This is because there is only one LOAD program header and rtld sets the size on the second and later LOAD headers.
I'm unsure why there is only one LOAD header as it is marked rwx. Adjusting the rtld logic fixes the build, however I'm unsure if we want to allow this from a security point of view (marking code as writeable).
Created attachment 200573 [details]
Possible rtld fix
This seems to be a bug in the base ld.bfd. If I link erlc with ld.lld I can complete the build, even without the rtld patch.
reopened as the problem still occurs
Andy is this something I should get addressed upstream in Erlang/OTP, or
is it something that FreeBSD needs to fix in base in 11.3?
the pkg builds fail continuously for 11.3/x86 at the moment and it would
be nice to address that as I've just deprecated all the older erlang
versions which are not supported by upstream :-)
If it's happening on 11.3 it's unrelated to the BSD crtbegin/crtend code. Said code is in 12 but disabled and enabled by default in 13.
thanks Andy, I'll need to look further then.