Re: libgcc double-free, backend won't die
От | Alvaro Herrera |
---|---|
Тема | Re: libgcc double-free, backend won't die |
Дата | |
Msg-id | 20071211152838.GH4708@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: hardware and For PostgreSQL (Ron St-Pierre <ron.pgsql@shaw.ca>) |
Ответы |
Re: libgcc double-free, backend won't die
Re: libgcc double-free, backend won't die |
Список | pgsql-performance |
Craig James wrote: > 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? Absolutely not. -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ "La gente vulgar solo piensa en pasar el tiempo; el que tiene talento, en aprovecharlo"
В списке pgsql-performance по дате отправления: