Re: unable to read core generated by valgrind in gdb / aarch64

[[Aggressive snipping, but relevant details preserved.]]

> No threading is used. Postgres is multi-process, and uses shared memory for the shared cache (through shm_open etc.).

Multi-process plus shm_open() IS THREADING!  Not pthreads, but multiple
execution contexts that read and write the same memory, which is
subject to the same types of synchronization errors as pthreads.
Perhaps --tool=drd and --tool=helgrind can help.


[[Another topic]]
> Sure, but that's more of a workaround - it does not make the core file useful, it provides alternative way to get to the same result. Plus it requires additional tooling/scripting, and I'd prefer keeping the tooling as simple as possible.

I made a specific suggestion that takes less than one hour: build a small test case
that performs a short chain of subroutine calls, with the last routine generating
a deliberate SIGABRT.  Run the test case under valgrind, get a core file from valgrind,
and see if gdb gives the correct traceback from that core file.  The objective
is to provide a strong clue about whether *every* core file generated by valgrind
(in your environment) fails to work well with gdb.  Perhaps solving the problem
that involves your larger and more-complex case can be subsumed by analyzing
something that is much simpler.

Please perform that experiment and report the results here.