Problem loading external functions; wrong version of libc?

[AsgerHB]

Hello
I am trying to load some external C code which I have written to have a dependency on <julia.h>, a library to call Julia functions in C.
I am on a 64-bit Ubuntu 22.04.1 LTS.

I have built my .so file using the following parameters

gcc -c -fPIC -o postshield.o
    -std=gnu99 -I'/opt/julia-1.8.0/include/julia' -fPIC
    -L'/opt/julia-1.8.0/lib' -Wl,--export-dynamic
    -Wl,-rpath,'/opt/julia-1.8.0/lib' -Wl,-rpath,'/opt/julia-1.8.0/lib/julia' -ljulia

And then

gcc -shared -o libpostshield.so
    -std=gnu99 -I'/opt/julia-1.8.0/include/julia' -fPIC
    -L'/opt/julia-1.8.0/lib' -Wl,--export-dynamic
    -Wl,-rpath,'/opt/julia-1.8.0/lib' -Wl,-rpath,'/opt/julia-1.8.0/lib/julia' -ljulia

This produces an .so file which I am able to load from another c program, to test it.
However, when I do the

import "/home/asger/libccpostshield.so"
{
     void initialize_julia_context();
};

in UPPAAL, the console gives the following error

ERROR: Unable to load dependent library /opt/julia-1.8.0/lib/julia/libjulia-internal.so.1
Message:/lib/x86_64-linux-gnu/librt.so.1: undefined symbol: __libc_unwind_link_get, version GLIBC_PRIVATE

Instructed by this readme I have gotten so far as building the newest glibc, into ~/.local/, but linking them seems to have no effect:

gcc -c -fPIC -I~/.local postshield.c -o postshield.o
    -std=gnu99 -I'/opt/julia-1.8.0/include/julia' -fPIC
    -L'/opt/julia-1.8.0/lib' -Wl,--export-dynamic
    -Wl,-rpath,'/opt/julia-1.8.0/lib' -Wl,-rpath,'/opt/julia-1.8.0/lib/julia' -ljulia

And then

gcc -shared -o libpostshield.so  -L~/.local postshield.o
    -std=gnu99 -I'/opt/julia-1.8.0/include/julia' -fPIC
    -L'/opt/julia-1.8.0/lib' -Wl,--export-dynamic
    -Wl,-rpath,'/opt/julia-1.8.0/lib' -Wl,-rpath,'/opt/julia-1.8.0/lib/julia' -ljulia

The exact same error occurs.

[mikucionisaau]

What UPPAAL version are you trying?

Maybe it's just a typo and it's not related, but your commands compile libpostshield.so, but UPPAAL model is asking for import libccpostshield.so (there's extra cc in the name).

Also, when you are linking against libraries in ~/.local, you need to add -L$HOME/.local/lib (which should contain libc.so.6), whereas -I adds only the headers, and I believe it needs to be -I$HOME/.local/include (which should contain math.h and similar headers). For this approach to work, you will also need to recompile the libjulia-internal.so.1 (and I guess lots more) against the libc in ~/.local.

Third thing: with newer OSes like Ubuntu-22, it should be easier to just remove the shipped libc out of the way, rename server.bin to server and retry (uppaal-4.1.26-2 is already patched like this, and Stratego-10 tries to handle such issues on-the-spot automatically).

[AsgerHB]

Updating UPPPAAL STRATEGO to the release version seems to have fixed the issue. I am now able to import the library and call functions.

Thanks a lot for being so helpful, and I apologize for not checking my UPPAAL version in advance 😅

Calling functions that do not make use of the Julia library works, which should be an indication that the linking issue has been fixed. However I get an error when trying to initialize the julia context,

Error: Unexpected EOF. Please terminate by issuing a 'quit' command.
at com.uppaal.engine.Engine$1.error(Engine.java:219)
at com.uppaal.engine.Engine.lambda$submitLicenseLess$1(Engine.java:769)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: Error: Unexpected EOF. Please terminate by issuing a 'quit' command.
at com.uppaal.engine.protocol.JsonMessageParser.expectNullableJsonToken(JsonMessageParser.java:271)
at com.uppaal.engine.protocol.JsonMessageParser.expectJsonToken(JsonMessageParser.java:290)
at com.uppaal.engine.protocol.JsonMessageParser.expectFieldName(JsonMessageParser.java:337)
at com.uppaal.engine.protocol.JsonMessageParser.visitStringField(JsonMessageParser.java:37)
at com.uppaal.engine.protocol.viewmodel.BasicResponse.accept(BasicResponse.java:24)
at com.uppaal.engine.protocol.JsonMessageParser.visitObject(JsonMessageParser.java:130)
at com.uppaal.engine.protocol.JsonMessageParser.visitObject(JsonMessageParser.java:144)
at com.uppaal.engine.protocol.JsonProtocol.getBasicResponse(JsonProtocol.java:467)
at com.uppaal.engine.protocol.JsonProtocol.getVersion(JsonProtocol.java:60)
at com.uppaal.engine.EngineStub.getVersion(EngineStub.java:228)
at com.uppaal.engine.Engine$1.run(Engine.java:211)
at com.uppaal.engine.Engine.lambda$submitLicenseLess$1(Engine.java:764)
... 3 more

but nothing in the console. Is there by chance a limit to how long it is allowed to run when processing declarations? Otherwise there are more things I can try.

Thanks again for the help!

[mikucionisaau]

No, there are no limits, just your patience.
The error messages are weird: it seems that the input-stream to the server is being closed (it gets EOF) and thus it reacts with "Please terminate with quit". If the GUI is terminating the stream, then it would not read this output. Very strange. Could it be some memory issues in your library and thus messes up with server's input stream/memory?

[mikucionisaau]

Or maybe julia is doing something with the standard input/output descriptors?

[mikucionisaau]

You can also try strace utility on verifyta to see what OS calls are being executed when you run into issues.

[AsgerHB]

I've looked more into it now. Surprisingly, the error only occurs in the GUI. Using verifyta it turns out I can execute queries as normal, which is what I was going to be using for my experiment.

That rules out memory issues.

What happens is, I spin up a Julia runtime to execute my code, and this I do with a C function initialize_julia_context. Noting that it re-evaluates declarations multiple times, I do a check in the function to make sure it hasn't run already. From my debug log I can see that it gets to the very end of the function, apparently returning without issue. (stderr is being used as general debug here because stdout causes an exception in the UI.)

int initialize_julia_context()
{
    if (already_running){
        fprintf(stderr, "Julia context already running.\n");
        return -1;
    }
    fprintf(stderr, "Starting....\n");  // UPPAAL gets confused when you print to stdout.

    jl_init();

    JULIA("include(\"" CODE_PATH "Experiment E/PostShield Strategy.jl\")");
    JULIA("strategy_path = " STRATEGY_PATH);
    JULIA("shield_path = " SHIELD_PATH);
    JULIA("shielded_strategy = get_shielded_strategy_int(strategy_path, shield_path)");
    JULIA("intervened = get_intervention_checker(strategy_path, shield_path)");
    fprintf(stderr, "Julia context started.\n");

    already_running = true;
    return 0;
}

However, right after I see the "Julia context started.\n" in the console, the error above occurs. Stripping the body of calls to julia removes this issue.

This may be too niche of an issue to investigate, but I did all this testing before discovering that direct calls to verifyta work, so I might as well post my findings 😁