pg11.1 jit segv

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Andres Freund <andres(at)anarazel(dot)de>
Subject: pg11.1 jit segv
Date: 2018-11-15 22:39:59
Message-ID: 20181115223959.GB10913@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Crash is reproducible but only when JIT=on.

postgresql11-llvmjit-11.1-1PGDG.rhel7.x86_64

[2769871.453033] postmaster[8582]: segfault at 7f083bddb780 ip 00007f08127e814e sp 00007ffe463506e0 error 4
[2770774.470600] postmaster[29410]: segfault at 7f0812eeb6c8 ip 00007f08127eb4f0 sp 00007ffe463506e0 error 4

Core was generated by `postgres: telsasoft ts 192.168.122.11(41908) SELECT '.
Program terminated with signal 11, Segmentation fault.

(gdb) bt
#0 0x00007f08127e814e in ?? ()
#1 0x0000000000000000 in ?? ()

[pryzbyj(at)database ~]$ sudo -u postgres valgrind /usr/pgsql-11/bin/postgres --single -D /var/lib/pgsql/11/data ts <tmp/sql-jit-crash-2018-11-15

==26448== Conditional jump or move depends on uninitialised value(s)
==26448== at 0x1B510F09: getAdjustedPtr(llvm::IRBuilder<llvm::ConstantFolder, (anonymous namespace)::IRBuilderPrefixedInserter>&, llvm::DataLayout const&, llvm::Value*, llvm::APInt, llvm::Type*, llvm::Twine) (SROA.cpp:1531)
==26448== by 0x1B511C52: llvm::sroa::AllocaSliceRewriter::getNewAllocaSlicePtr(llvm::IRBuilder<llvm::ConstantFolder, (anonymous namespace)::IRBuilderPrefixedInserter>&, llvm::Type*) (SROA.cpp:2313)
==26448== by 0x1B516BA0: llvm::sroa::AllocaSliceRewriter::visitIntrinsicInst(llvm::IntrinsicInst&) (SROA.cpp:2921)
==26448== by 0x1B5190CC: visitCall (Instruction.def:190)
==26448== by 0x1B5190CC: llvm::InstVisitor<llvm::sroa::AllocaSliceRewriter, bool>::visit(llvm::Instruction&) (Instruction.def:190)
==26448== by 0x1B51947A: visit (InstVisitor.h:114)
==26448== by 0x1B51947A: llvm::sroa::AllocaSliceRewriter::visit((anonymous namespace)::Slice const*) (SROA.cpp:2262)
==26448== by 0x1B51D426: llvm::SROA::rewritePartition(llvm::AllocaInst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (SROA.cpp:3921)
==26448== by 0x1B51E630: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (SROA.cpp:4029)
==26448== by 0x1B51F25D: llvm::SROA::runOnAlloca(llvm::AllocaInst&) (SROA.cpp:4156)
==26448== by 0x1B52048A: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (SROA.cpp:4243)
==26448== by 0x1B520E40: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (SROA.cpp:4296)
==26448== by 0x1AC49C31: llvm::FPPassManager::runOnFunction(llvm::Function&) (LegacyPassManager.cpp:1514)
==26448== by 0x1B6A805E: RunPassOnSCC (Timer.h:149)
==26448== by 0x1B6A805E: RunAllPassesOnSCC (CallGraphSCCPass.cpp:419)
==26448== by 0x1B6A805E: (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (CallGraphSCCPass.cpp:474)
==26448==
==26448== Conditional jump or move depends on uninitialised value(s)
==26448== at 0x1B510F09: getAdjustedPtr(llvm::IRBuilder<llvm::ConstantFolder, (anonymous namespace)::IRBuilderPrefixedInserter>&, llvm::DataLayout const&, llvm::Value*, llvm::APInt, llvm::Type*, llvm::Twine) (SROA.cpp:1531)
==26448== by 0x1B511C52: llvm::sroa::AllocaSliceRewriter::getNewAllocaSlicePtr(llvm::IRBuilder<llvm::ConstantFolder, (anonymous namespace)::IRBuilderPrefixedInserter>&, llvm::Type*) (SROA.cpp:2313)
==26448== by 0x1B515EF0: llvm::sroa::AllocaSliceRewriter::visitMemSetInst(llvm::MemSetInst&) (SROA.cpp:2656)
==26448== by 0x1B5190CC: visitCall (Instruction.def:190)
==26448== by 0x1B5190CC: llvm::InstVisitor<llvm::sroa::AllocaSliceRewriter, bool>::visit(llvm::Instruction&) (Instruction.def:190)
==26448== by 0x1B51947A: visit (InstVisitor.h:114)
==26448== by 0x1B51947A: llvm::sroa::AllocaSliceRewriter::visit((anonymous namespace)::Slice const*) (SROA.cpp:2262)
==26448== by 0x1B51D426: llvm::SROA::rewritePartition(llvm::AllocaInst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (SROA.cpp:3921)
==26448== by 0x1B51E630: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (SROA.cpp:4029)
==26448== by 0x1B51F25D: llvm::SROA::runOnAlloca(llvm::AllocaInst&) (SROA.cpp:4156)
==26448== by 0x1B52048A: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (SROA.cpp:4243)
==26448== by 0x1B520E40: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (SROA.cpp:4296)
==26448== by 0x1AC49C31: llvm::FPPassManager::runOnFunction(llvm::Function&) (LegacyPassManager.cpp:1514)
==26448== by 0x1B6A805E: RunPassOnSCC (Timer.h:149)
==26448== by 0x1B6A805E: RunAllPassesOnSCC (CallGraphSCCPass.cpp:419)
==26448== by 0x1B6A805E: (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (CallGraphSCCPass.cpp:474)
==26448==

==26448== Invalid write of size 8
==26448== at 0x4C2E0C3: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1022)
==26448== by 0x824075: UnknownInlinedFun (string3.h:51)
==26448== by 0x824075: varstrfastcmp_locale (varlena.c:2135)
==26448== by 0x87C6F3: ApplySortComparator (sortsupport.h:224)
==26448== by 0x87C6F3: comparetup_heap (tuplesort.c:3560)
==26448== by 0x8793F4: qsort_tuple (qsort_tuple.c:112)
==26448== by 0x87EE53: tuplesort_performsort (tuplesort.c:1811)
==26448== by 0x628CE2: ExecSort (nodeSort.c:118)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x610D48: UnknownInlinedFun (executor.h:237)
==26448== by 0x610D48: fetch_input_tuple (nodeAgg.c:406)
==26448== by 0x61277F: agg_retrieve_direct (nodeAgg.c:1736)
==26448== by 0x61277F: ExecAgg (nodeAgg.c:1551)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x60A764: ExecScanFetch (execScan.c:95)
==26448== by 0x60A764: ExecScan (execScan.c:162)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== Address 0x1f77c1c0 is 0 bytes after a block of size 8,192 alloc'd
==26448== at 0x4C29C23: malloc (vg_replace_malloc.c:299)
==26448== by 0x86D5AD: AllocSetContextCreateExtended (aset.c:477)
==26448== by 0x87AA3D: tuplesort_begin_common (tuplesort.c:697)
==26448== by 0x87DAA9: tuplesort_begin_heap (tuplesort.c:812)
==26448== by 0x628C93: ExecSort (nodeSort.c:89)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x610D48: UnknownInlinedFun (executor.h:237)
==26448== by 0x610D48: fetch_input_tuple (nodeAgg.c:406)
==26448== by 0x61277F: agg_retrieve_direct (nodeAgg.c:1736)
==26448== by 0x61277F: ExecAgg (nodeAgg.c:1551)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x60A764: ExecScanFetch (execScan.c:95)
==26448== by 0x60A764: ExecScan (execScan.c:162)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x61B364: UnknownInlinedFun (executor.h:237)
==26448== by 0x61B364: MultiExecPrivateHash (nodeHash.c:164)
==26448== by 0x61B364: MultiExecHash (nodeHash.c:114)
==26448==
==26448== Invalid read of size 8
==26448== at 0x4C2E0CE: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1022)
==26448== by 0x824075: UnknownInlinedFun (string3.h:51)
==26448== by 0x824075: varstrfastcmp_locale (varlena.c:2135)
==26448== by 0x87C6F3: ApplySortComparator (sortsupport.h:224)
==26448== by 0x87C6F3: comparetup_heap (tuplesort.c:3560)
==26448== by 0x8793F4: qsort_tuple (qsort_tuple.c:112)
==26448== by 0x87EE53: tuplesort_performsort (tuplesort.c:1811)
==26448== by 0x628CE2: ExecSort (nodeSort.c:118)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x610D48: UnknownInlinedFun (executor.h:237)
==26448== by 0x610D48: fetch_input_tuple (nodeAgg.c:406)
==26448== by 0x61277F: agg_retrieve_direct (nodeAgg.c:1736)
==26448== by 0x61277F: ExecAgg (nodeAgg.c:1551)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x60A764: ExecScanFetch (execScan.c:95)
==26448== by 0x60A764: ExecScan (execScan.c:162)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== Address 0x1f77e200 is 0 bytes after a block of size 8,192 alloc'd
==26448== at 0x4C29C23: malloc (vg_replace_malloc.c:299)
==26448== by 0x86D5AD: AllocSetContextCreateExtended (aset.c:477)
==26448== by 0x87AA5A: tuplesort_begin_common (tuplesort.c:710)
==26448== by 0x87DAA9: tuplesort_begin_heap (tuplesort.c:812)
==26448== by 0x628C93: ExecSort (nodeSort.c:89)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x610D48: UnknownInlinedFun (executor.h:237)
==26448== by 0x610D48: fetch_input_tuple (nodeAgg.c:406)
==26448== by 0x61277F: agg_retrieve_direct (nodeAgg.c:1736)
==26448== by 0x61277F: ExecAgg (nodeAgg.c:1551)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x60A764: ExecScanFetch (execScan.c:95)
==26448== by 0x60A764: ExecScan (execScan.c:162)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x61B364: UnknownInlinedFun (executor.h:237)
==26448== by 0x61B364: MultiExecPrivateHash (nodeHash.c:164)
==26448== by 0x61B364: MultiExecHash (nodeHash.c:114)
==26448==
==26448== Invalid read of size 8
==26448== at 0x4C2E0C0: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1022)
==26448== by 0x824075: UnknownInlinedFun (string3.h:51)
==26448== by 0x824075: varstrfastcmp_locale (varlena.c:2135)
==26448== by 0x87C6F3: ApplySortComparator (sortsupport.h:224)
==26448== by 0x87C6F3: comparetup_heap (tuplesort.c:3560)
==26448== by 0x8793F4: qsort_tuple (qsort_tuple.c:112)
==26448== by 0x87EE53: tuplesort_performsort (tuplesort.c:1811)
==26448== by 0x628CE2: ExecSort (nodeSort.c:118)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x610D48: UnknownInlinedFun (executor.h:237)
==26448== by 0x610D48: fetch_input_tuple (nodeAgg.c:406)
==26448== by 0x61277F: agg_retrieve_direct (nodeAgg.c:1736)
==26448== by 0x61277F: ExecAgg (nodeAgg.c:1551)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x60A764: ExecScanFetch (execScan.c:95)
==26448== by 0x60A764: ExecScan (execScan.c:162)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== Address 0x1f77e210 is 16 bytes after a block of size 8,192 alloc'd
==26448== at 0x4C29C23: malloc (vg_replace_malloc.c:299)
==26448== by 0x86D5AD: AllocSetContextCreateExtended (aset.c:477)
==26448== by 0x87AA5A: tuplesort_begin_common (tuplesort.c:710)
==26448== by 0x87DAA9: tuplesort_begin_heap (tuplesort.c:812)
==26448== by 0x628C93: ExecSort (nodeSort.c:89)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x610D48: UnknownInlinedFun (executor.h:237)
==26448== by 0x610D48: fetch_input_tuple (nodeAgg.c:406)
==26448== by 0x61277F: agg_retrieve_direct (nodeAgg.c:1736)
==26448== by 0x61277F: ExecAgg (nodeAgg.c:1551)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x60A764: ExecScanFetch (execScan.c:95)
==26448== by 0x60A764: ExecScan (execScan.c:162)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x61B364: UnknownInlinedFun (executor.h:237)
==26448== by 0x61B364: MultiExecPrivateHash (nodeHash.c:164)
==26448== by 0x61B364: MultiExecHash (nodeHash.c:114)
==26448==
==26448==
==26448== More than 10000000 total errors detected. I'm not reporting any more.
==26448== Final error counts will be inaccurate. Go fix your program!
==26448== Rerun with --error-limit=no to disable this cutoff. Note
==26448== that errors may occur in your program without prior warning from
==26448== Valgrind, because errors are no longer being displayed.
==26448==
==26448==
==26448== Process terminating with default action of signal 11 (SIGSEGV)
==26448== Access not within mapped region at address 0x23337000
==26448== at 0x4C2E0CE: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1022)
==26448== by 0x824075: UnknownInlinedFun (string3.h:51)
==26448== by 0x824075: varstrfastcmp_locale (varlena.c:2135)
==26448== by 0x87C6F3: ApplySortComparator (sortsupport.h:224)
==26448== by 0x87C6F3: comparetup_heap (tuplesort.c:3560)
==26448== by 0x8793F4: qsort_tuple (qsort_tuple.c:112)
==26448== by 0x87EE53: tuplesort_performsort (tuplesort.c:1811)
==26448== by 0x628CE2: ExecSort (nodeSort.c:118)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x610D48: UnknownInlinedFun (executor.h:237)
==26448== by 0x610D48: fetch_input_tuple (nodeAgg.c:406)
==26448== by 0x61277F: agg_retrieve_direct (nodeAgg.c:1736)
==26448== by 0x61277F: ExecAgg (nodeAgg.c:1551)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== by 0x60A764: ExecScanFetch (execScan.c:95)
==26448== by 0x60A764: ExecScan (execScan.c:162)
==26448== by 0x609067: ExecProcNodeInstr (execProcnode.c:461)
==26448== If you believe this happened as a result of a stack
==26448== overflow in your program's main thread (unlikely but
==26448== possible), you can try to increase the size of the
==26448== main thread stack using the --main-stacksize= flag.
==26448== The main thread stack size used in this run was 8388608.
=
Let me know if there's anything else I can provide.

Justin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-11-15 22:43:04 Re: pgsql: Add flag values in WAL description to all heap records
Previous Message Kevin Grittner 2018-11-15 22:36:49 Re: In-place updates and serializable transactions