From: John R. <jr...@bi...> - 2022-09-09 16:20:24
|
[[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. |