Issues compiling static binaries on Alpine Linux

92 views
Skip to first unread message

ocon...@gmail.com

unread,
Jun 17, 2016, 2:07:37 PM6/17/16
to dev-cfengine
(Sorry if you're also subscribed to the help-cfengine@ list. Also, this list doesn't accept file uploads, but no one was going to run my binaries anyway!)

Hi,

I'm trying to compile a set of static CFEngine binaries on Alpine Linux (musl libc). My goal is to be able to scp a small tarball to an arbitrary linux x86_64 and have it setup a working cfengine environment. This would be very difficult to do using glibc or dynamic binaries. 

Anyway, I can generate a statically linked binary, but when I run it on my policy, I get:

  error: Could not open database txn /var/cfengine/state/cf_lock.lmdb: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot
  error: Could not open database txn /var/cfengine/state/cf_lock.lmdb: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot
  error: Could not open database txn /var/cfengine/state/cf_lock.lmdb: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot
  error: Could not open database txn /var/cfengine/state/cf_lock.lmdb: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot
  error: Could not open database txn /var/cfengine/state/cf_lock.lmdb: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot
...
fish: “sudo /var/cfengine/bin/cf-agent” terminated by signal SIGSEGV (Address boundary error)

I am compiling against LMDB tagged "LMDB_0.9.18" in the openldap git repository. Also, pcre-8.38, and openssl-1.0.1t. I've been able to replicate this on both cfengine 3.8.2 and 3.9.0. 

Any ideas on what could be causing this issue?

Thanks,
Eric

Eric O'Connor

unread,
Jun 17, 2016, 2:28:30 PM6/17/16
to dev-cfengine
I just turned off strip in my deploy script, so I could get the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004a1fc3 in mdb_get (txn=0xffffffffffffffff, dbi=1, key=key@entry=0x7ffffffef3b0, data=data@entry=0x7ffffffef3c0) at mdb.c:5580
5580    mdb.c: No such file or directory.
(gdb) bt
#0  0x00000000004a1fc3 in mdb_get (txn=0xffffffffffffffff, dbi=1, key=key@entry=0x7ffffffef3b0, data=data@entry=0x7ffffffef3c0) at mdb.c:5580
#1  0x000000000043c664 in DBPrivRead (db=0xa9af40, key=key@entry=0x7ffffffef430, key_size=<optimized out>, dest=dest@entry=0x7ffffffef410, dest_size=dest_size@entry=24) at dbm_lmdb.c:444
#2  0x000000000043b99d in ReadDB (handle=handle@entry=0x8ffeb0 <db_handles+720>, key=key@entry=0x7ffffffef430 "CF_CRITICAL_SECTION", dest=dest@entry=0x7ffffffef410, destSz=destSz@entry=24) at dbm_api.c:464
#3  0x00000000004616eb in FindLockTime (name=name@entry=0x6298c9 "CF_CRITICAL_SECTION") at locks.c:196
#4  0x0000000000461e15 in WaitForCriticalSection (section_id=0x6298c9 "CF_CRITICAL_SECTION") at locks.c:325
#5  0x0000000000462510 in AcquireLock (ctx=ctx@entry=0x9180c0, operand=operand@entry=0xbb45a0 "/home/ec/.config/fish/config.fish", host=<optimized out>, now=1466187981, tc=..., pp=pp@entry=0xbb9a80, ignoreProcesses=false) at locks.c:711
#6  0x00000000004051cb in VerifyFilePromise (ctx=ctx@entry=0x9180c0, path=path@entry=0xbb45a0 "/home/ec/.config/fish/config.fish", pp=pp@entry=0xbb9a80) at verify_files.c:284
#7  0x000000000042f5b8 in LocateFilePromiserGroup (ctx=ctx@entry=0x9180c0, wildpath=0xbb45a0 "/home/ec/.config/fish/config.fish", pp=pp@entry=0xbb9a80, fnptr=fnptr@entry=0x404ed0 <VerifyFilePromise>) at promiser_regex_resolver.c:62
#8  0x0000000000405d4a in FindFilePromiserObjects (pp=0xbb9a80, ctx=0x9180c0) at verify_files.c:803
#9  FindAndVerifyFilesPromises (ctx=ctx@entry=0x9180c0, pp=pp@entry=0xbb9a80) at verify_files.c:783
#10 0x0000000000401c7d in ParallelFindAndVerifyFilesPromises (pp=0xbb9a80, ctx=0x9180c0) at cf-agent.c:1818
#11 KeepAgentPromise (ctx=ctx@entry=0x9180c0, pp=pp@entry=0xbb9a80, param=param@entry=0x0) at cf-agent.c:1589
#12 0x0000000000453f49 in ExpandPromiseAndDo (param=0x0, ActOnPromise=0x4015c0 <KeepAgentPromise>, containers=<optimized out>, lists=<optimized out>, pp=0xbb6760, ctx=0x9180c0) at expand.c:238
#13 ExpandPromise (ctx=ctx@entry=0x9180c0, pp=pp@entry=0x9b5120, ActOnPromise=ActOnPromise@entry=0x4015c0 <KeepAgentPromise>, param=param@entry=0x0) at expand.c:164
#14 0x0000000000402fdc in ScheduleAgentOperations (ctx=ctx@entry=0x9180c0, bp=bp@entry=0x9bcb60) at cf-agent.c:1304
#15 0x000000000041175a in VerifyMethod (ctx=ctx@entry=0x9180c0, call=..., a=..., pp=pp@entry=0x9cb8e0) at verify_methods.c:180
#16 0x0000000000411d3a in VerifyMethodsPromise (ctx=ctx@entry=0x9180c0, pp=pp@entry=0x9cb8e0) at verify_methods.c:75
#17 0x0000000000401c5b in KeepAgentPromise (ctx=ctx@entry=0x9180c0, pp=pp@entry=0x9cb8e0, param=param@entry=0x0) at cf-agent.c:1613
#18 0x0000000000453f49 in ExpandPromiseAndDo (param=0x0, ActOnPromise=0x4015c0 <KeepAgentPromise>, containers=<optimized out>, lists=<optimized out>, pp=0x9c5cc0, ctx=0x9180c0) at expand.c:238
#19 ExpandPromise (ctx=ctx@entry=0x9180c0, pp=pp@entry=0x9bc940, ActOnPromise=ActOnPromise@entry=0x4015c0 <KeepAgentPromise>, param=param@entry=0x0) at expand.c:164
#20 0x0000000000402fdc in ScheduleAgentOperations (ctx=ctx@entry=0x9180c0, bp=bp@entry=0x9c2c60) at cf-agent.c:1304
#21 0x0000000000400d50 in KeepPromiseBundles (config=0x918020, config=0x918020, policy=0x9d93a0, ctx=0x9180c0) at cf-agent.c:1218
#22 KeepPromises (config=0x918020, policy=0x9d93a0, ctx=0x9180c0) at cf-agent.c:693
#23 main (argc=<optimized out>, argv=<optimized out>) at cf-agent.c:248

Kristian Amlie

unread,
Jun 20, 2016, 2:26:37 AM6/20/16
to ocon...@gmail.com, dev-cfengine
This is interesting, I don't think I have seen static compilation of
CFEngine being attempted before. I'm not aware of specific things that
would break when compiling statically (other than the Enterprise
version, but that's irrelevant here), but quite a few subtle things
change when doing so, so mileage may vary. The message is unknown to me,
and it's not immediately obvious why a static compile would trigger
this, AFAIK LMDB doesn't use any fancy DLL magic. Your best bet might be
to ask on the openldap list, where LMDB is being developed. If they
can't answer the static compile, maybe they can at least tell you what
the message means.

If you do get a reply, but don't know where to go from there, feel free
to post it here, maybe we'll know more then.

--
Kristian
Reply all
Reply to author
Forward
0 new messages