Re: PANIC: wrong buffer passed to visibilitymap_clear

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PANIC: wrong buffer passed to visibilitymap_clear
Date: 2021-04-09 23:30:44
Message-ID: 20210409233044.g3ucnqp5yy67wkd2@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-04-09 16:27:12 -0700, Peter Geoghegan wrote:
> They're both VACUUM ANALYZE. They must be, because the calls to
> visibilitymap_clear PANIC (they don't ERROR) -- the failing
> visibilitymap_clear() call must occur inside a critical section, and
> all such calls are made within heapam.c (only VACUUM ANALYZE uses a
> transaction and does writes). It cannot be the two calls to
> visibilitymap_clear() inside vacuumlazy.c.

There's a stacktrace at the bottom of the spurfowl report:

======-=-====== stack trace: pgsql.build/src/test/regress/tmp_check/data/core ======-=-======
[New LWP 24172]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: autovacuum worker regression '.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f77a7967428 in __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 0x00007f77a7967428 in __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007f77a796902a in __GI_abort () at abort.c:89
#2 0x000000000095cf8d in errfinish (filename=<optimized out>, filename(at)entry=0x9c3fa0 "visibilitymap.c", lineno=lineno(at)entry=155, funcname=funcname(at)entry=0x9c41c0 <__func__.13853> "visibilitymap_clear") at elog.c:680
#3 0x0000000000501498 in visibilitymap_clear (rel=rel(at)entry=0x7f77a96d2d28, heapBlk=<optimized out>, buf=buf(at)entry=0, flags=flags(at)entry=3 '\\003') at visibilitymap.c:155
#4 0x00000000004e6380 in heap_update (relation=relation(at)entry=0x7f77a96d2d28, otid=otid(at)entry=0x2c0394c, newtup=newtup(at)entry=0x2c03948, cid=0, crosscheck=crosscheck(at)entry=0x0, wait=wait(at)entry=true, tmfd=0x7ffe119d2c20, lockmode=0x7ffe119d2c1c) at heapam.c:3993
#5 0x00000000004e7d70 in simple_heap_update (relation=relation(at)entry=0x7f77a96d2d28, otid=otid(at)entry=0x2c0394c, tup=tup(at)entry=0x2c03948) at heapam.c:4211
#6 0x00000000005811a9 in CatalogTupleUpdate (heapRel=0x7f77a96d2d28, otid=0x2c0394c, tup=0x2c03948) at indexing.c:309
#7 0x00000000005efc32 in update_attstats (relid=16928, inh=inh(at)entry=false, natts=natts(at)entry=1, vacattrstats=vacattrstats(at)entry=0x2b3c030) at analyze.c:1746
#8 0x00000000005f264a in update_attstats (vacattrstats=0x2b3c030, natts=1, inh=false, relid=<optimized out>) at analyze.c:589
#9 do_analyze_rel (onerel=onerel(at)entry=0x7f77a95c1070, params=params(at)entry=0x2aba36c, va_cols=va_cols(at)entry=0x0, acquirefunc=<optimized out>, relpages=33, inh=inh(at)entry=false, in_outer_xact=false, elevel=13) at analyze.c:589
#10 0x00000000005f2d8d in analyze_rel (relid=<optimized out>, relation=<optimized out>, params=params(at)entry=0x2aba36c, va_cols=0x0, in_outer_xact=<optimized out>, bstrategy=<optimized out>) at analyze.c:261
#11 0x0000000000671721 in vacuum (relations=0x2b492b8, params=params(at)entry=0x2aba36c, bstrategy=<optimized out>, bstrategy(at)entry=0x2aba4e8, isTopLevel=isTopLevel(at)entry=true) at vacuum.c:478
#12 0x000000000048f02d in autovacuum_do_vac_analyze (bstrategy=0x2aba4e8, tab=0x2aba368) at autovacuum.c:3316
#13 do_autovacuum () at autovacuum.c:2537
#14 0x0000000000779d76 in AutoVacWorkerMain (argv=0x0, argc=0) at autovacuum.c:1715
#15 0x0000000000779e79 in StartAutoVacWorker () at autovacuum.c:1500
#16 0x0000000000788324 in StartAutovacuumWorker () at postmaster.c:5539
#17 sigusr1_handler (postgres_signal_arg=<optimized out>) at postmaster.c:5243
#18 <signal handler called>
#19 0x00007f77a7a2f5b3 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:84
#20 0x0000000000788668 in ServerLoop () at postmaster.c:1701
#21 0x000000000078a187 in PostmasterMain (argc=argc(at)entry=8, argv=argv(at)entry=0x2a408c0) at postmaster.c:1409
#22 0x0000000000490e48 in main (argc=8, argv=0x2a408c0) at main.c:209
$1 = {si_signo = 6, si_errno = 0, si_code = -6, _sifields = {_pad = {24172, 1001, 0 <repeats 26 times>}, _kill = {si_pid = 24172, si_uid = 1001}, _timer = {si_tid = 24172, si_overrun = 1001, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _rt = {si_pid = 24172, si_uid = 1001, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _sigchld = {si_pid = 24172, si_uid = 1001, si_status = 0, si_utime = 0, si_stime = 0}, _sigfault = {si_addr = 0x3e900005e6c, _addr_lsb = 0, _addr_bnd = {_lower = 0x0, _upper = 0x0}}, _sigpoll = {si_band = 4299262287468, si_fd = 0}}}

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-04-09 23:32:03 Re: PANIC: wrong buffer passed to visibilitymap_clear
Previous Message Andres Freund 2021-04-09 23:27:39 Re: PANIC: wrong buffer passed to visibilitymap_clear