Re: JIT compiling with LLVM v12.2 - Mailing list pgsql-hackers

On Thu, Mar 22, 2018 at 9:06 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-03-21 23:10:27 +1300, Thomas Munro wrote:
>> Next up, I have an arm64 system running Debian 9.4.  It bombs in
>> "make check" and in simple tests:
>
> Hum. Is it running a 32bit or 64 bit kernel/os?

checking size of void *... 8

>> ./configure \
>>   --prefix=$HOME/install \
>>   --enable-cassert \
>>   --enable-debug \
>>   --with-llvm \
>>   CC="ccache gcc" \
>>   CXX="ccache g++" \
>>   CLANG="ccache /usr/lib/llvm-3.9/bin/clang" \
>>   LLVM_CONFIG="/usr/lib/llvm-3.9/bin/llvm-config"
>
> I guess you'd swapped out 3.9 for 5.0?

Right, in the second backtrace I showed it was 5.0 (for both clang and
llvm-config).

>> I can provide access to this thing if you think that'd be useful.
>
> Perhaps that's necessary. Before that though, could you check how the
> backtrace looks with LLVM debug symbols installed?

After installing libllvm3.9-dgb:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x0000ffffa1ae1df4 in __GI_abort () at abort.c:89
#2  0x0000ffff9634ee40 in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#3  0x0000ffff9634cd4c in ?? () from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
#4  0x0000ffff9634cd98 in std::terminate() () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
#5  0x0000ffff9634d01c in __cxa_throw () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
#6  0x0000ffff963754bc in std::__throw_bad_function_call() () from
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
warning: Could not find DWO CU
CMakeFiles/LLVMOrcJIT.dir/OrcCBindings.cpp.dwo(0x691f70a1d71f901d)
referenced by CU at offset 0x11ffa [in module
/usr/lib/debug/.build-id/09/04bb3e707305e175216a59bc3598c2b194775a.debug]
#7  0x0000ffff97697a2c in LLVMOrcCreateInstance () at
/usr/include/c++/6/functional:2126
#8  0x0000ffff98accdb0 in llvm_session_initialize () at llvmjit.c:643
#9  llvm_create_context (jitFlags=9) at llvmjit.c:136
#10 0x0000ffff98ad78c8 in llvm_compile_expr (state=0xaaaafce73208) at
llvmjit_expr.c:132
#11 0x0000aaaac1bd671c in ExecReadyExpr
(state=state@entry=0xaaaafce73208) at execExpr.c:627
#12 0x0000aaaac1bd97b8 in ExecBuildProjectionInfo
(targetList=<optimized out>, econtext=<optimized out>, slot=<optimized
out>, parent=parent@entry=0xaaaafce72de0,
inputDesc=inputDesc@entry=0x0) at execExpr.c:471
#13 0x0000aaaac1bec028 in ExecAssignProjectionInfo
(planstate=planstate@entry=0xaaaafce72de0,
inputDesc=inputDesc@entry=0x0) at execUtils.c:460
#14 0x0000aaaac1c08a28 in ExecInitResult
(node=node@entry=0xaaaafcdc11a0, estate=estate@entry=0xaaaafce72bc8,
eflags=eflags@entry=16) at nodeResult.c:221
#15 0x0000aaaac1be7828 in ExecInitNode (node=0xaaaafcdc11a0,
node@entry=0xaaaafcded630, estate=estate@entry=0xaaaafce72bc8,
eflags=eflags@entry=16) at execProcnode.c:164
#16 0x0000aaaac1be2a70 in InitPlan (eflags=16,
queryDesc=0xaaaafcde0808) at execMain.c:1051
#17 standard_ExecutorStart (queryDesc=0xaaaafcde0808, eflags=16) at
execMain.c:266
#18 0x0000aaaac1d39bec in PortalStart (portal=0x400,
portal@entry=0xaaaafce234d8, params=0x274580612ce0a285,
params@entry=0x0, eflags=43690, eflags@entry=0,
snapshot=0xaaaac1fa9f58, snapshot@entry=0x0) at pquery.c:520
#19 0x0000aaaac1d34b18 in exec_simple_query
(query_string=query_string@entry=0xaaaafcdbf3d8 "select 42;") at
postgres.c:1082
#20 0x0000aaaac1d366a8 in PostgresMain (argc=<optimized out>,
argv=argv@entry=0xaaaafcdebb90, dbname=<optimized out>,
username=<optimized out>) at postgres.c:4147
#21 0x0000aaaac1a28dd0 in BackendRun (port=0xaaaafcde0410) at postmaster.c:4409
#22 BackendStartup (port=0xaaaafcde0410) at postmaster.c:4081
#23 ServerLoop () at postmaster.c:1754
#24 0x0000aaaac1cb7048 in PostmasterMain (argc=<optimized out>,
argv=<optimized out>) at postmaster.c:1362
#25 0x0000aaaac1a2a7cc in main (argc=3, argv=0xaaaafcdb9f70) at main.c:228

GDB also printed a ton of messages like this for many LLVM .cpp files:

warning: Could not find DWO CU
CMakeFiles/LLVMLibDriver.dir/LibDriver.cpp.dwo(0x117022032f862080)
referenced by CU at offset 0x187da [in module
/usr/lib/debug/.build-id/09/04bb3e707305e175216a59bc3598c2b194775a.debug]
...

We can see that it's missing some debug info, any clues about that?
Here's LLVM 3.9's LLVMOrcCreateInstance function:


https://github.com/llvm-mirror/llvm/blob/6531c3164cb9edbfb9f4b43ca383810a94ca5aa0/lib/ExecutionEngine/Orc/OrcCBindings.cpp#L15

Without digging through more source code I'm not sure which line of
that is invoking our uninvocable std::function...

The server also prints this:

terminate called after throwing an instance of 'std::bad_function_call'
  what():  bad_function_call

Aside from whatever problem is causing this, we can see that there is
no top-level handling of exceptions.  That's probably fine if we are
in a no throw scenario (unless there is something seriously corrupted,
as is probably the case here), and it seems that we must be because
we're accessing this code via its C API.

-- 
Thomas Munro
http://www.enterprisedb.com