jvmkill fails to load inside a garden container

[glyn]

Attempting to use jvmkill in a garden container caused a JVM startup failure:

Error occurred during initialization of VM
Could not find agent library /home/vcap/app/.java-buildpack/open_jdk_jre/bin/jvmkill-1.0.2 in absolute path, with error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /home/vcap/app/.java-buildpack/open_jdk_jre/bin/jvmkill-1.0.2)

Analysing the dependencies of jvmkill (built on ubuntu trusty) showed:

$ ldd libjvmkill.so
        linux-vdso.so.1 =>  (0x00007ffc33913000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd417c77000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd417971000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd4175ac000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd4181a7000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd417396000)

Setting LD_DEBUG=all produces these diagnostics.

To recreate the failure, cf push a simple Java application (e.g. the web application of these tests) with this commit of the Java buildpack set to be master of a fork of the Java buildpack and the fork specified using the cf push -b flag.

[Zteve]

Well, those diagnostics seem pretty comprehensive. What part of that don't you understand? :smiley:

[glyn]

Some more diagnostics to add to our lack of understanding:

$ readelf -d libjvmkill.so

Dynamic section at offset 0x29d20 contains 27 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libJvmKill]
 0x000000000000000c (INIT)               0x15920
 0x000000000000000d (FINI)               0x23d4c
 0x0000000000000019 (INIT_ARRAY)         0x229a20
 0x000000000000001b (INIT_ARRAYSZ)       40 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x229a48
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1f0
 0x0000000000000005 (STRTAB)             0x5028
 0x0000000000000006 (SYMTAB)             0x14d0
 0x000000000000000a (STRSZ)              53807 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x22a000
 0x0000000000000002 (PLTRELSZ)           10344 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x130b8
 0x0000000000000007 (RELA)               0x12800
 0x0000000000000008 (RELASZ)             2232 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x12750
 0x000000006fffffff (VERNEEDNUM)         2
 0x000000006ffffff0 (VERSYM)             0x12258
 0x000000006ffffff9 (RELACOUNT)          7
 0x0000000000000000 (NULL)               0x0

[glyn]

Running inside a docker container loaded from image cloudfoundry/cflinuxfs2, only C++ ABI versions up to 1.3.7 are available, whereas our agent currently needs 1.3.8. Investigating why there is this mismatch. If the runtime container cannot provide 1.3.8, one option is to downgrade the gcc toolchain, e.g. to gcc 4.7, before building the agent.

[Zteve]

Just a suggestion: build the jvmkill library on the same container you wish to run it in. (Well; a copy, obviously.)

[nebhale]

@Zteve Yep, this is what we're doing now.

[glyn]

Working now.