Problem loading a library with FFI in PHP 7.4

Question

I'm having trouble using a third party .so library in PHP with the new FFI. When I run this little piece of code:

<?php

$ffi = FFI::cdef('typedef int (*NFE_Nome)(const char* sNome, int* esTamanho);', 'libacbrnfe64.so');

PHP outputs me this error:

double free or corruption (out)
Aborted (core dumped)

Is this a problem with the library itself, my PHP configuration or something else? It's confusing to me, because I can use normally this same library with this C++ code:

#include <iostream>
#include <dlfcn.h>

typedef int (*NFE_Nome)(const char* sNome, int* esTamanho);

#define BUFFER_LEN 256

int main() {
    void *lib = dlopen("libacbrnfe64.so", RTLD_LAZY);

    auto libMethod = (NFE_Nome) dlsym(lib, "NFE_Nome");

    const std::string bufferNome(BUFFER_LEN, ' ');
    int bufferNomeLength = BUFFER_LEN;

    libMethod(bufferNome.c_str(), &bufferNomeLength);

    std::cout << bufferNome << std::endl;
    return 0;
}

I'm aware that the PHP code doesn't execute the NFE_Nome function, but I'm getting the error before trying to call the function itself.

Answer 1

-- Edit --

This problem is result of two bugs in two different programs.

1. When linking a shared objects, fpc-3.0.0 (or newer) adds this to the dependencies (as the first dependency): /lib64/ld-linux-x86-64.so.2

2. ld-linux-x86-64.so.2 exports a calloc variant, that doesn't (always) clears the memory it returns (details below)

The workaround OP suggested is linking in a separate pass (using -E (or -Cn) option of fpc), but before running ./ppas.sh fixing link.res file. For that, I hacked this awk-script, but I do feel it a bit clumsy:

#!/usr/bin/awk -f
$0=="INPUT(" { state=1; next; }
$0=="/lib64/ld-linux-x86-64.so.2" { state=2; next; }
$0==")" && state>0 { state=0;next; }
state==1 { print "INPUT("; state=0; }
{ print $0; }

-- Original answer --

Sounds like a linking problem: you might have added /lib64/ld-linux-x86-64.so.2 into the dependent shared libraries, which is neither required or useful.

Actually, it resulted a calloc version that returns non-zeroed memory. The details are described here: https://www.linuxquestions.org/questions/programming-9/debugging-dlopen-4175668676/ and here: Why does calling calloc in gdb not appear to zero out the memory?

Suggested solution: change the linkage according to the example:

- gcc -shared -o demodule.so demodule.o /lib64/ld-linux-x86-64.so.2 -lglib-2.0
+ gcc -shared -o demodule.so demodule.o -lglib-2.0

The difference can be checked with readelf -d. Wrong:

Dynamic section at offset 0x828 contains 26 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Right output:

Dynamic section at offset 0x7f8 contains 25 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Also, with command ldd demodule.so the line containing /lib64/ld-linux-x86-64.so.2 should be the last one.

Edit: discussion on sourceware.org regarding this problem: https://sourceware.org/bugzilla/show_bug.cgi?id=25486

Edit: on Freepascal side: https://bugs.freepascal.org/view.php?id=36706