Re: libgcc double-free, backend won't die
От | Alvaro Herrera |
---|---|
Тема | Re: libgcc double-free, backend won't die |
Дата | |
Msg-id | 20071211152010.GE10710@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: libgcc double-free, backend won't die (Craig James <craig_james@emolecules.com>) |
Ответы |
Re: libgcc double-free, backend won't die
|
Список | pgsql-performance |
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. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC "When the proper man does nothing (wu-wei), his thought is felt ten thousand miles." (Lao Tse)
В списке pgsql-performance по дате отправления: