Re: [IBM z Systems] Getting server crash when jit_above_cost =0

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [IBM z Systems] Getting server crash when jit_above_cost =0
Date: 2020-04-21 21:10:25
Message-ID: CA+hUKGLgffHewoJ3Fkzg=n4T00YWVqnd=yS0x7d7zz7WQCH5jA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 22, 2020 at 2:34 AM tushar <tushar(dot)ahuja(at)enterprisedb(dot)com> wrote:
> (gdb) bt
> #0 0x000003ffa9841220 in raise () from /lib64/libc.so.6
> #1 0x000003ffa9842aa8 in abort () from /lib64/libc.so.6
> #2 0x000003ff9f7881b4 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6
> #3 0x000003ff9f785c7e in ?? () from /lib64/libstdc++.so.6
> #4 0x000003ff9f785cb6 in std::terminate() () from /lib64/libstdc++.so.6
> #5 0x000003ff9f785f60 in __cxa_throw () from /lib64/libstdc++.so.6
> #6 0x000003ff9f7e4468 in std::__throw_bad_function_call() () from /lib64/libstdc++.so.6
> #7 0x000003ffa139e5c4 in std::function<std::unique_ptr<llvm::orc::IndirectStubsManager, std::default_delete<llvm::orc::IndirectStubsManager> > ()>::operator()() const () from /opt/rh/llvm-toolset-6.0/root/usr/lib64/libLLVM-6.0.so
> #8 0x000003ffa139f2a8 in LLVMOrcCreateInstance () from /opt/rh/llvm-toolset-6.0/root/usr/lib64/libLLVM-6.0.so
> #9 0x000003ffa9c8a984 in llvm_session_initialize () at llvmjit.c:670
> #10 llvm_create_context (jitFlags=<optimized out>) at llvmjit.c:146
> #11 0x000003ffa9c98992 in llvm_compile_expr (state=0xa8c52218) at llvmjit_expr.c:131
> #12 0x0000000080219986 in ExecReadyExpr (state=state(at)entry=0xa8c52218) at execExpr.c:628
> #13 0x000000008021cd6e in ExecBuildProjectionInfo (targetList=<optimized out>, econtext=<optimized out>, slot=<optimized out>, parent=parent(at)entry=0xa8c51e30, inputDesc=inputDesc(at)entry=0x0) at execExpr.c:472
> #14 0x0000000080232ed6 in ExecAssignProjectionInfo (planstate=planstate(at)entry=0xa8c51e30, inputDesc=inputDesc(at)entry=0x0) at execUtils.c:504
> #15 0x0000000080250178 in ExecInitResult (node=node(at)entry=0xa8c4fb98, estate=estate(at)entry=0xa8c51bf0, eflags=eflags(at)entry=16) at nodeResult.c:221
> #16 0x000000008022c72c in ExecInitNode (node=node(at)entry=0xa8c4fb98, estate=estate(at)entry=0xa8c51bf0, eflags=eflags(at)entry=16) at execProcnode.c:164
> #17 0x000000008022675e in InitPlan (eflags=16, queryDesc=0xa8c4f7d0) at execMain.c:1020
> #18 standard_ExecutorStart (queryDesc=0xa8c4f7d0, eflags=16) at execMain.c:266
> #19 0x0000000080388868 in PortalStart (portal=portal(at)entry=0xa8c91c80, params=params(at)entry=0x0, eflags=eflags(at)entry=0, snapshot=snapshot(at)entry=0x0) at pquery.c:518
> #20 0x0000000080384b2e in exec_simple_query (query_string=query_string(at)entry=0xa8c06170 "select 5;") at postgres.c:1176
> #21 0x00000000803852e0 in PostgresMain (argc=<optimized out>, argv=argv(at)entry=0xa8c55db8, dbname=0xa8c55c80 "postgres", username=<optimized out>) at postgres.c:4247
> #22 0x000000008008007e in BackendRun (port=<optimized out>, port=<optimized out>) at postmaster.c:4437
> #23 BackendStartup (port=0xa8c4dc10) at postmaster.c:4128
> #24 ServerLoop () at postmaster.c:1704
> #25 0x000000008030c89e in PostmasterMain (argc=argc(at)entry=3, argv=argv(at)entry=0xa8c00cc0) at postmaster.c:1377
> #26 0x00000000800811f4 in main (argc=<optimized out>, argv=0xa8c00cc0) at main.c:228

Hi Tushar,

When testing this stuff on a few different platforms, I ran into a
switch statement in llvm that returned an empty std::function<> that
would throw std::bad_function_call like that, on architectures other
than (IIRC) x86 and ARM:

https://www.postgresql.org/message-id/CAEepm%3D39F_B3Ou8S3OrUw%2BhJEUP3p%3DwCu0ug-TTW67qKN53g3w%40mail.gmail.com

I'm not sure if you're seeing the same problem or another similar one,
but I know that Andres got a patch along those lines into llvm. Maybe
you could try on a more recent llvm release?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jehan-Guillaume de Rorthais 2020-04-21 21:19:33 Re: Remove non-fast promotion Re: Should we remove a fallback promotion? take 2
Previous Message Robert Haas 2020-04-21 21:09:50 Re: design for parallel backup