On Thu, Mar 22, 2018 at 9:06 AM, Andres Freund <and...@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
