From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | segfault tied to "IS JSON predicate" commit |
Date: | 2023-04-14 04:14:01 |
Message-ID: | CAH2-Wz=EVXdxcO91KEiaEvc8=sDbeBFjEjX1raqi3aFZzrGgdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I find that if I run the following test against a standard debug build
on HEAD, my local installation reliably segfaults:
$ meson test --setup running --suite test_rls_hooks-running
Attached is a "bt full" run from gdb against a core dump. The query
"EXPLAIN (costs off) SELECT * FROM rls_test_permissive;" runs when the
backend segfaults.
The top frame of the back trace is suggestive of a use-after-free:
#0 copyObjectImpl (from=0x7f7f7f7f7f7f7f7e) at copyfuncs.c:187
187 switch (nodeTag(from))
...
"git bisect" suggests that the problem began at commit 6ee30209,
"SQL/JSON: support the IS JSON predicate".
It's a bit surprising that the bug reproduces when I run a standard
test, and yet we appear to have a bug that's about 2 weeks old. There
may be something unusual about my system that will turn out to be
relevant -- though there is nothing particularly exotic about this
machine. My repro doesn't rely on concurrent execution, or timing, or
anything like that -- it's quite reliable.
--
Peter Geoghegan
Attachment | Content-Type | Size |
---|---|---|
bt-full-segfault.txt | text/plain | 24.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2023-04-14 04:19:35 | RE: pg_upgrade and logical replication |
Previous Message | Michael Paquier | 2023-04-14 04:13:09 | Re: Various typo fixes |