[[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. _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
