Josh Kupershmidt <schmiddy@gmail.com> writes:
> Here's a backtrace from 9.1 tip with CFLAGS="-O0", server logs are as before:
> Program received signal SIGBUS, Bus error.
> 0x00c9716b in ?? () from /lib/i386-linux-gnu/libc.so.6
> (gdb) bt
> #0 0x00c9716b in ?? () from /lib/i386-linux-gnu/libc.so.6
> #1 0x082b3b2f in ReadBuffer_common (smgr=0x9ef68d0, relpersistence=112 'p',
> forkNum=MAIN_FORKNUM, blockNum=86781, mode=RBM_ZERO, strategy=0x0,
> hit=0xbfc5eeff "") at bufmgr.c:435
> #2 0x082b3722 in ReadBufferWithoutRelcache (rnode=..., forkNum=MAIN_FORKNUM,
> blockNum=86781, mode=RBM_ZERO, strategy=0x0) at bufmgr.c:272
> #3 0x080df3a0 in XLogReadBufferExtended (rnode=..., forknum=MAIN_FORKNUM,
> blkno=86781, mode=RBM_ZERO) at xlogutils.c:296
> #4 0x080d0bab in RestoreBkpBlocks (lsn=..., record=0x9eed480,
> cleanup=0 '\000') at xlog.c:3589
> #5 0x080eb1b8 in gin_redo (lsn=..., record=0x9eed480) at ginxlog.c:678
[ scratches head... ] Well, that proves the previous backtrace wasn't
lying to us, but it's hard to see how this happens. AFAICT this could
only mean that the buffer pointer returned by BufHdrGetBlock is bad,
and how could that happen? I'm suspicious that there must be something
broken about your VM environment. Can you reproduce it outside the VM,
or even better create a reproducible test case?
regards, tom lane
