unable to read core generated by valgrind in gdb / aarch64

Hi,

I'm having some issues with analyzing cores generated from valgrind. I 
do get the core file, but when I try opening it in gdb it just shows 
some entirely bogus information / backtrace etc.

This is a rpi4 machine, with 64-bit debian, running a local build of 
valgrind 3.19.0 (built from sources, not a package).

This is how I run the program (postgres binary)

   valgrind --quiet --trace-children=yes --track-origins=yes \
   --read-var-info=yes --num-callers=20 --leak-check=no \
   --gen-suppressions=all --error-limit=no \
   --log-file=/tmp/valgrind.543917.log postgres \
   -D /home/debian/postgres /contrib/test_decoding/tmp_check_iso/data \
   -F -c listen_addresses= -k /tmp/pg_regress-n7HodE

I get a ~200MB core file in /tmp, which I try loading like this:

   gdb src/backend/postgres /tmp/valgrind.542299.log.core.542391

but all I get is this:

   Reading symbols from src/backend/postgres...
   [New LWP 542391]
   Cannot access memory at address 0xcc10cc00cbf0cc6
   Cannot access memory at address 0xcc10cc00cbf0cbe
   Core was generated by `'.
   Program terminated with signal SIGABRT, Aborted.
   #0  0x00000000049d42ac in ?? ()
   (gdb) bt
   #0  0x00000000049d42ac in ?? ()
   #1  0x0000000000400000 in dshash_dump (hash_table=0x0) at dshash.c:782
   #2  0x0000000000400000 in dshash_dump (hash_table=0x49c0e44) at 
dshash.c:782
   #3  0x0000000000000000 in ?? ()
   Backtrace stopped: previous frame identical to this frame (corrupt 
stack?)

So the stack might be corrupt, for some reason? The first part looks 
entirely bogus too, though. The file size seems about right - with 128MB 
shared buffers, 200MB might be about right.

The core is triggered by an "assert" in the source, and we even log a 
backtrace into the log - and that seems much more plausible:

   TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: 
"reorderbuffer.c", Line: 902, PID: 536049)
   (ExceptionalCondition+0x98)[0x8f5cec]
   (+0x57a574)[0x682574]
   (+0x579edc)[0x681edc]
   (ReorderBufferAddNewTupleCids+0x60)[0x6864dc]
   (SnapBuildProcessNewCid+0x94)[0x68b6a4]
   (heap2_decode+0x17c)[0x671584]
   (LogicalDecodingProcessRecord+0xbc)[0x670cd0]
   (+0x570f88)[0x678f88]
   (pg_logical_slot_get_changes+0x1c)[0x6790fc]
   (ExecMakeTableFunctionResult+0x29c)[0x4a92c0]
   (+0x3be638)[0x4c6638]
   (+0x3a2c14)[0x4aac14]
   (ExecScan+0x8c)[0x4aaca8]
   (+0x3bea14)[0x4c6a14]
   (+0x39ea60)[0x4a6a60]
   (+0x392378)[0x49a378]
   (+0x39520c)[0x49d20c]
   (standard_ExecutorRun+0x214)[0x49aad8]
   (ExecutorRun+0x64)[0x49a8b8]
   (+0x62e2ac)[0x7362ac]
   (PortalRun+0x27c)[0x735f08]
   (+0x626be8)[0x72ebe8]
   (PostgresMain+0x9a0)[0x733e9c]
   (+0x547be8)[0x64fbe8]
   (+0x547540)[0x64f540]
   (+0x542d30)[0x64ad30]
   (PostmasterMain+0x1460)[0x64a574]
   (+0x418888)[0x520888]

Clearly, this is not an issue valgrind is meant to detect (like invalid 
memory access, etc.) but an application issue. I've tried reproducing it 
without valgrind, but it only ever happens with valgrind - my theory is 
it's some sort of race condition, and valgrind changes the timing in a 
way that makes it much more likely to hit. I need to analyze the core to 
inspect the state more closely, etc.

Any ideas what I might be doing wrong? Or how do I load the core file?


thanks
Tomas