Re: libgcc double-free, backend won't die
От | Craig James |
---|---|
Тема | Re: libgcc double-free, backend won't die |
Дата | |
Msg-id | 475EABD6.2020200@emolecules.com обсуждение исходный текст |
Ответ на | Re: libgcc double-free, backend won't die (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-performance |
Alvaro Herrera wrote: > Craig James wrote: >> Alvaro Herrera wrote: >>> Craig James wrote: >>> >>>> Here is my guess -- and this is just a guess. My functions use a >>>> third-party library which, of necessity, uses malloc/free in the >>>> ordinary way. I suspect that there's a bug in the Postgres palloc() >>>> code that's walking over memory that regular malloc() allocates. The >>>> third-party library (OpenBabel) has been tested pretty thoroughly by >>>> me an others and has no memory corruption problems. All malloc's are >>>> freed properly. Does that seem like a possibility? >>> Not really. palloc uses malloc underneath. >> But some Postgres code could be walking off the end of a malloc'ed >> block, even if palloc() is allocating and deallocating correctly. >> Which is why I was hoping to use valgrind to see what's going on. > > I very much doubt it. Since you've now shown that OpenBabel is > multithreaded, then that's a much more likely cause. Can you elaborate? Are multithreaded libraries not allowed to be linked to Postgres? Thanks, Craig
В списке pgsql-performance по дате отправления: