pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17589: Invalid read at array_positions
2+ messages / 2 participants
[nested] [flat]
* BUG #17589: Invalid read at array_positions
@ 2022-08-17 12:11 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2022-08-17 12:11 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: tharakan@gmail.com
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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #17589: Invalid read at array_positions
@ 2022-08-17 13:24 Robins Tharakan <tharakan@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 0 replies; 2+ messages in thread
From: Robins Tharakan @ 2022-08-17 13:24 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2022-08-17 13:24 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-08-17 12:11 BUG #17589: Invalid read at array_positions PG Bug reporting form <noreply@postgresql.org>
2022-08-17 13:24 ` Robins Tharakan <tharakan@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox