Lightning LibJIT interoperability issue

[dschwen]

I encountered a curious issue when using both LibJIT and Lightning in
the same program. The issue occurs on Linux, but not on macOS.
Here is a minimal working example (compile with g++ -g -o test test.C -ljit -llightning):

extern "C"
{
#include <lightning.h>
}

#include "jit/jit.h"

void test()
{
  auto jit_context = jit_context_create();
}

int main()
{
  init_jit(nullptr);
  auto _jit = jit_new_state();
  jit_clear_state();
}

When run this will fail at the lightning jit_clear_state(); call.

debugging details

The program outputs

free(): invalid pointer
Aborted (core dumped)

Running in the debugger I see

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7924859 in __GI_abort () at abort.c:79
#2  0x00007ffff798f3ee in __libc_message
(action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7ab9285 "%s\n") at
../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff799747c in malloc_printerr
(str=str@entry=0x7ffff7ab74ae "free(): invalid pointer") at
malloc.c:5347
#4  0x00007ffff7998cac in _int_free (av=<optimized out>, p=<optimized
out>, have_lock=0) at malloc.c:4173
#5  0x00007ffff7afc213 in _jit_clear_state (_jit=0x555555559580) at
lightning.c:908
#6  0x00005555555551dd in main () at test.C:17

#5  0x00007ffff7afc213 in _jit_clear_state (_jit=0x555555559580) at
lightning.c:908
908     jit_free((jit_pointer_t *)&_jitc->data.table);
(gdb) print *_jit
$1 = {pc = {uc = 0x0, us = 0x0, ui = 0x0, ul = 0x0, w = 0}, code =
{ptr = 0x0, length = 0}, data = {ptr = 0x0, length = 0}, note = {ptr =
0x0, length = 1}, comp = 0x5555555595d0, user_code = 0, user_data = 0}
(gdb) print *_jit->comp
$2 = {head = 0x0, tail = 0x0, prepare = 0x0, realize = 0, dataset = 0,
done = 0, emit = 0, again = 0, synth = 0, no_data = 0, no_note = 0,
reglen = 40, regarg = 0, regsav = 0, reglive = 0, regmask = 0, code =
{end = 0x0}, data = {ptr = 0x0, table = 0x0, size = 0, count = 0,
offset = 0}, spill = 0x555555559700, gen = 0x555555559850,
  values = 0x555555559900, blocks = {ptr = 0x55555555e480, offset = 0,
length = 16}, patches = {ptr = 0x555555559cd0, offset = 0, length =
1024}, function = 0x0, functions = {ptr = 0x55555555dce0, offset = 0,
length = 16}, pool = {ptr = 0x55555555e3f0, offset = 0, length = 16},
list = 0x0, note = {head = 0x0, tail = 0x0, size = 40,
    name = 0x0, note = 0x0, base = 0x0}}

Note that test() is never called. So just linking to libjit causes the
issue. If the function body is entirely omitted the bug does not occur
(I'm suspecting some linker optimization results in not triggering a
symbol conflict... maybe?)

[M4GNV5]

Hey,

it looks like _jit_clear_state is passing an invalid pointer to free.

Here is the source code line of lightning. _jitc is defined to be _jit->comp in jit_private.h. Thus the call is actually a free(_jit->comp->data.table).

Could you try printing that value before it is passed to free? You could also try running your example with valgrind, maybe it finds something useful.

lightning has a lot of quirks normally not used in C programming. the hidden _jit parameter and the _jitc are just two of them. I would bet a hack similar to one of those two causes the issue. Or it is simply caused by a struct name used by both libjit and lightning. In the latter case you could try calling g++ with -Wall.

[dschwen]

Yeah, the struct with the pointer is private (accessing it from the user code is pretty difficult because you do not have access to the full declaration). The value is in the debugging details above (you can unfold those). -Wall didn't yield anything and valgrind only shows a delete of an invalid pointer. :-/

The quirks are just a bunch of macro definitions. I've already followed those down (again see the folded up details in the original issue text).

I'll investigate the libraries for symbol collisions. I wonder why the linker wouldn't complain here...

[dschwen]

D'uh, trying to statically link revealed the issue:

g++ --static -o test test.C  -ljit -llightning  -pthread
/usr/bin/ld: /usr/local/lib/liblightning.a(jit_memory.o): in function `jit_memcpy':
/home/schwd/Programs/lightning/lib/jit_memory.c:44: multiple definition of `jit_memcpy'; /usr/local/lib/libjit.a(jit-util.o):/home/schwd/Programs/libjit/jit/jit-util.c:160: first defined here
/usr/bin/ld: /usr/local/lib/liblightning.a(jit_memory.o): in function `jit_memmove':
/home/schwd/Programs/lightning/lib/jit_memory.c:52: multiple definition of `jit_memmove'; /usr/local/lib/libjit.a(jit-util.o):/home/schwd/Programs/libjit/jit/jit-util.c:185: first defined here
/usr/bin/ld: /usr/local/lib/liblightning.a(jit_memory.o): in function `jit_realloc':
/home/schwd/Programs/lightning/lib/jit_memory.c:92: multiple definition of `jit_realloc'; /usr/local/lib/libjit.a(jit-util.o):/home/schwd/Programs/libjit/jit/jit-util.c:106: first defined here
/usr/bin/ld: /usr/local/lib/liblightning.a(jit_memory.o): in function `jit_free':
/home/schwd/Programs/lightning/lib/jit_memory.c:100: multiple definition of `jit_free'; /usr/local/lib/libjit.a(jit-util.o):/home/schwd/Programs/libjit/jit/jit-util.c:116: first defined here
collect2: error: ld returned 1 exit status

Both libs define jit_memcpy, jit_memmove, jit_realloc, and jit_free :-/

[dschwen]

Reversing the linking order g++ -g -o test test.C -llightning -ljit moves the crash inti libjit (somewhat unsurprisingly) :-D

[dschwen]

Ok, dschwen/lightning@268bd6c fixes this issue for me.

This is a scenario were each library developer could conveniently just point the finger at the other library. However, lightning's offending symbols are not part of the public API (unlike the LibJIT symbols I believe), so I suggested a rename to the lighting developer.

[M4GNV5]

I guess we can close this issue then?