problem with ccall in v1.0

[pixelate]

Hi there
in version 0.6.4 this runs perfectly:
cfi = “/tcenas/home/anderson/lib/eocfi/lib/LINUX64/xxx/xx/libcfi.so”
v = ccall((:xl_verbose,cfi),Void,())

but in version 1.0 the lines:
cfi = “/tcenas/home/anderson/lib/eocfi/lib/LINUX64/xxx/xx/libcfi.so”
v = ccall((:xl_verbose,cfi),CVoid,())

produce the error:
signal (11): Segmentation fault
in expression starting at /tcenas/home/anderson/julia/bb.jl:8
_ZN4llvm3Use3setEPNS_5ValueE at /usr/local/bin/julia-1.0.0/bin/…/lib/julia/libLLVM-6.0.so (unknown line)
_ZN4llvm8LoadInstC2EPNS_4TypeEPNS_5ValueEPKcbPNS_11InstructionE at /usr/local/bin/julia-1.0.0/bin/…/lib/julia/libLLVM-6.0.so (unknown line)
CreateLoad at /buildworker/worker/package_linux64/build/usr/include/llvm/IR/IRBuilder.h:1175
emit_varinfo at /buildworker/worker/package_linux64/build/src/codegen.cpp:3374
emit_expr at /buildworker/worker/package_linux64/build/src/codegen.cpp:3455
…

Any help, guidance or a solution to this problem would very be very much appreciated.
Craig

[nalimilan]

The replacement for Void is Cvoid, not CVoid. Is that a typo? Can you give more details on the called function?

[pixelate]

yep, that was a typo and it should have been “Cvoid” in the example code (it was “Cvoid” in the program that produces the error,) Sorry.
The called function is part of a large library and just sets an internal flag so that other functions know to print errors and warnings to stdout,

[nalimilan]

Without a way to reproduce the problem I’m afraid it will be hard to help. If you can’t make the library available to Julia developers, you could try to get a better backtrace using the julia-debug excutable, and/or by running it under Valgrind.

[Liso]

@pixelate

_ZN4llvm8LoadInstC2EPNS_4TypeEPNS_5ValueEPKcbPNS_11InstructionE at /usr/local/bin/julia-1.0.0/bin/…/lib/julia/libLLVM-6.0.so (unknown line)
CreateLoad at /buildworker/worker/package_linux64/build/usr/include/llvm/IR/IRBuilder.h:1175

I would be suspicios about mixing llvm versions…

What is ldd /tcenas/home/anderson/lib/eocfi/lib/LINUX64/xxx/xx/libcfi.so output?

EDIT: I think that @jpsamaroo is right.

[jpsamaroo]

I’m pretty sure that’s just a path that’s baked in while Julia binaries are being compiled by the official buildbots.

[pixelate]

OK, I will create a simple library that I can make available and see if the problem reoccurs (but I suspect that the problem is independent of the library because if I deliberately give the wrong path name to the library then I get the same error message). I will do this next week and in the meantime thanks for your interest and suggestions.

[Liso]

I tried but have no problem. Here is my MWE:

/tmp/solib$ cat a.cpp
#include <fstream>

extern "C" {
void fnc(){
    std::ofstream f("/tmp/out");
    f << "hello" << std::endl;
    f.close();
}
}

Building library:

/tmp/solib$ g++ -shared -fPIC a.cpp -o a.so

I had to restart Julia after changes in library!

julia> ccall((:fnc, "/tmp/solib/a.so"), Cvoid, ())

shell> cat /tmp/out
hello

[jpsamaroo]

If you get this even with an invalid library name, then it’s probably a Julia bug. I noticed that you’re running Julia 1.0.0, which has had numerous segfault issues addressed in more recent versions. Any chance you could upgrade to 1.0.1 and retry?

[rdeits]

This might be the line that segfaults, but is it the only ccall in your code? Did you perhaps pass some Julia data structure to your library in an earlier call? It could be the case that you’ve passed some Julia object to C, that object was no longer referenced on the Julia side and was therefore garbage collected, and then your C code tried to use that object, resulting in a use-after-free error. The GC in 0.7/1.0 seems to be a bit better at freeing objects as soon as they’re no longer referenced by Julia, which has had a side effect of making bugs like the one I described more obvious.

Of course without more info about what your code is doing, I’m really just guessing.

[pixelate]

Hi jpsamaroo and nalimilan

C code:
#include <stdio.h>
int test( ) { printf(“testy\n”); return 999; }

compiled with:
gcc -shared -fPIC test.c -o libtest.so

julia code:
lib = “/tcenas/home/anderson/julia/xxx/libtest.so”
v = ccall((:test,lib),Int32,())
println(v)

Runs perfectly with 0.6.4 and segfaults with 1.0.0
So now I will install 1.0.1 and retry …

[nalimilan]

Works here on 1.0.1 (after replacing the lib argument with the literal path).

[pixelate]

Well I installed 1.0.1 and retried and the example still segfaults with the same error message as before. This is disappointing.

But interestingly the example code provided by Liso (thanks Liso!) seems to run ok (but did not print anything to stdout).

As soon as I get time I will play around a bit and see if I can work out what is causing the situation.

[nalimilan]

Can you post the exact Julia code you used? As I noted I had to do this instead, since ccall needs a literal string:

v = ccall((:test, "/tcenas/home/anderson/julia/xxx/libtest.so"), Cint, ())

[pixelate]

Hi nalimilan

The file test.c contains:

#include <stdio.h>
int test( )
{
printf(“testy\n”);
return 999;
}

and is compiled with

gcc -shared -fPIC test.c -o libtest.so

and the julia file m.jl contains:

function test()
lib = “/tcenas/home/anderson/julia/xxx/libtest.so”
v = ccall((:test,lib),Int32,())
println(v)
end

println(“hello”)
test()
println(“ok”)

where /tcenas/home/anderson/julia/xxx/libtest.so is the full pathname to the output file produced by gcc.

The julia program works fine with 0.6.4 but segfaults with 1.0.0 and 1.0.1

[pixelate]

… and bizarrely when I change the key line in the julia code to

v = ccall((:test,“/tcenas/home/anderson/julia/xxx/libtest.so”),Int32,())

or just

v = ccall((:test,“./libtest.so”),Int32,())

then everything works just fine.

This makes no sense to me but a working program is better than one that segfaults!

[kristoffer.carlsson]

PSA: how to quote code with backticks

This is a short post on using backticks (` and ```) to quote code, with the intention of benefiting users who are confused by this feature of the site. The intention is to make it linkable when necessary. Why By quoting your code, you get a monospaced font (which preserves indentation) and syntax highlighting. This helps people who read your code and want to help you. Displayed code looks like this: function displayed_code(x::Int, y::Int) if x < y println("x is smaller") else …

[PetrKryslUCSD]

@pixelate

v = ccall((:test,“./libtest.so”),Int32,())

Confirmed with Ubuntu in a Windows Linux Subsystem
Linux Firebolt 4.4.0-17134-Microsoft #285-Microsoft Thu Aug 30 17:31:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux

Bizarre!

[pixelate]

ok, looking more closely at the documentation for v0.6 and v1.0 I find:

Shared libraries and functions are referenced by a tuple of the form (:function, "library")

so it seems that (a) the library name must be a literal string, and (b) this wasn’t enforced in 0.6 but is necessary in 1.0

It looks like the whole saga has been caused by me not reading the docs with enough attention to detail. My apologies for this, and many thanks to everyone who has taken the time to post suggestions and tips here.

[nalimilan]

But I wouldn’t expect a segfault. Do you really mean that it crashes? Can you get a backtrace?