Обсуждение: BUG #17589: Invalid read at array_positions
The following bug has been logged on the website: Bug reference: 17589 Logged by: Robins Tharakan Email address: tharakan@gmail.com PostgreSQL version: 14.5 Operating system: Ubuntu 20.04 Description: A valgrind enabled sqlsmith run threw this error. ==00:02:14:21.521 213966== VALGRINDERROR-BEGIN ==00:02:14:21.522 213966== Invalid read of size 4 ==00:02:14:21.522 213966== at 0x78169C: array_positions (array_userfuncs.c:806) ==00:02:14:21.522 213966== by 0x49C841: ExecInterpExpr (execExprInterp.c:741) ==00:02:14:21.522 213966== by 0x49ED30: ExecInterpExprStillValid (execExprInterp.c:1882) ==00:02:14:21.522 213966== by 0x4BABE5: ExecEvalExprSwitchContext (executor.h:343) ==00:02:14:21.522 213966== by 0x4BAC5D: ExecProject (executor.h:377) ==00:02:14:21.522 213966== by 0x4BB11E: ExecScan (execScan.c:238) ==00:02:14:21.522 213966== by 0x4FD1F8: ExecSeqScan (nodeSeqscan.c:112) ==00:02:14:21.522 213966== by 0x4B6C54: ExecProcNodeFirst (execProcnode.c:463) ==00:02:14:21.522 213966== by 0x4F257B: ExecProcNode (executor.h:259) ==00:02:14:21.522 213966== by 0x4F7CFC: ExecModifyTable (nodeModifyTable.c:3529) ==00:02:14:21.522 213966== by 0x4B6C54: ExecProcNodeFirst (execProcnode.c:463) ==00:02:14:21.522 213966== by 0x4AA229: ExecProcNode (executor.h:259) ==00:02:14:21.522 213966== Address 0x4ed9d28 is 344 bytes inside a block of size 8,192 alloc'd ==00:02:14:21.522 213966== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==00:02:14:21.522 213966== by 0x93DB39: AllocSetContextCreateInternal (aset.c:469) ==00:02:14:21.522 213966== by 0x4C01BE: CreateExprContextInternal (execUtils.c:253) ==00:02:14:21.522 213966== by 0x4C02A6: CreateExprContext (execUtils.c:303) ==00:02:14:21.522 213966== by 0x4C0541: ExecAssignExprContext (execUtils.c:482) ==00:02:14:21.522 213966== by 0x4E7CBE: ExecInitIndexScan (nodeIndexscan.c:1078) ==00:02:14:21.522 213966== by 0x4B668D: ExecInitNode (execProcnode.c:219) ==00:02:14:21.522 213966== by 0x4FA9EB: ExecInitNestLoop (nodeNestloop.c:302) ==00:02:14:21.522 213966== by 0x4B685E: ExecInitNode (execProcnode.c:297) ==00:02:14:21.522 213966== by 0x4EA43B: ExecInitLimit (nodeLimit.c:478) ==00:02:14:21.522 213966== by 0x4B6A4B: ExecInitNode (execProcnode.c:380) ==00:02:14:21.522 213966== by 0x4AB719: InitPlan (execMain.c:938) ==00:02:14:21.522 213966== ==00:02:14:21.522 213966== VALGRINDERROR-END Version: 93f2349c36@master $ uname -a Linux ip-172-31-3-183 5.15.0-1015-aws #19~20.04.1-Ubuntu SMP Wed Jun 22 19:07:51 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Command used: valgrind --leak-check=no --track-origins=yes --read-var-info=yes --gen-suppressions=all --suppressions=${PGSOURCE}/src/tools/valgrind.supp --time-stamp=yes --error-markers=VALGRINDERROR-BEGIN,VALGRINDERROR-END --log-file=${PGTEMP}/valgrind/%p.log --trace-children=yes ${PGTEMP}/bin/pg_ctl -D ${PGTEMP}/data -l ${PGTEMP}/logfile start I can't reproduce this but I'd be interested in knowing whether another set of (valgrind or other) flags may help better in triaging here. If nothing else works, I'll try to enable log_statement=all for future runs, but that really slows things down and I'd prefer to keep that as a last resort. Thanks
On Wed, 17 Aug 2022 at 21:42, PG Bug reporting form <noreply@postgresql.org> wrote: > If nothing else works, I'll try to enable log_statement=all for > future runs, but that really slows things down and I'd prefer to > keep that as a last resort. On re-reading the wiki, it seems that unless the trace throws something obvious (to the eye), log-statement=all is a reliable way to triage further. Will retry a few more runs with logging and come back in case I find something. Sorry for the noise. - robins