Tom Lane wrote:
>My suspicion is that it's an incompatibility between malloc() >libraries. On Linux there's only supposed to be one malloc, ie, glibc's version. On other platforms I'd be worried about threaded vs non-threaded libc (because the backend is not threaded), but not Linux.
I guess I misinterpreted the Postgress manual, which says (in 31.9, "C Language Functions"), "When allocating memory, use the PostgreSQL functions palloc and pfree instead of the corresponding C library functions malloc and free." I imagined that perhaps palloc/pfree used mutexes for something. But if I understand you, palloc() and pfree() are just wrappers around malloc() and free(), and don't (for example) make their own separate calls to brk(2), sbrk(2), or their kin. If that's the case, then you answered my question - it's all ordinary malloc/free calls in the end, and that's not the source of the problem.
There may be a more basic threading problem here, though, rooted in the precise fact that the backend isn't threaded. If you're trying to use any libraries that assume they can have multiple threads, I wouldn't be at all surprised to see things go boom.
No threading anywhere. None of the libraries use threads or mutexes. It's just plain old vanilla C/C++ scientific algorithms.
C++ exception handling could be problematic too.
No C++ exceptions are thrown anywhere in the code, 'tho I suppose one of the I/O libraries could throw an exception, e.g. when reading from a file. But there's no evidence of this after millions of identical operations succeeded. In addition, the stack trace shows it to be stuck in a memory operation, not an I/O operation.
Or it could be a garden variety glibc bug. How up-to-date is your platform?
I guess this is the next place to look. From the few answers I've gotten, it sounds like this isn't a known Postgres issue, and my stack trace doesn't seem to be familiar to anyone on this forum. Oh well... thanks for your help. Craig
