Thread: Check for failed memory allocations in libpq
Attached is a patch (against 7.3.4) to check the return values of some calls (malloc, realloc, etc.) for failed memory allocations in libpq. -- Dave Allen daveallen@acm.org
Attachment
Dave Allen <daveallen@acm.org> writes: > Attached is a patch (against 7.3.4) to check the return values of some > calls (malloc, realloc, etc.) for failed memory allocations in libpq. You sure you aren't just trading one misbehavior for another? The change in PQmakeEmptyPGresult, for example, just moves the core dump somewhere else, unless you find reasonable fallbacks for *all* its callers (including applications you don't have the source code for, but in any case including every one of the calls in libpq). regards, tom lane
Apologies if I missed anything, but I thought I fixed any callers of PQmakeEmptyPQresult that weren't already checking (parseInput and getRowDescriptions were the only ones). I of course can't fix any applications I don't have the source for, but if I missed something in libpq, I'd be more than happy to go back and try to fix it. On Thu, 2003-07-31 at 07:05, Tom Lane wrote: > Dave Allen <daveallen@acm.org> writes: > > Attached is a patch (against 7.3.4) to check the return values of some > > calls (malloc, realloc, etc.) for failed memory allocations in libpq. > > You sure you aren't just trading one misbehavior for another? The > change in PQmakeEmptyPGresult, for example, just moves the core dump > somewhere else, unless you find reasonable fallbacks for *all* its > callers (including applications you don't have the source code for, > but in any case including every one of the calls in libpq). > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Dave Allen daveallen@acm.org
Dave Allen <daveallen@acm.org> writes: >> You sure you aren't just trading one misbehavior for another? > Apologies if I missed anything, but I thought I fixed any callers of > PQmakeEmptyPQresult that weren't already checking (parseInput and > getRowDescriptions were the only ones). Well, I'm concerned about the global implications. For instance, I think making parseInput simply return on malloc failure *without doing any more* will convert out-of-memory from a core dump into an infinite loop; which is hardly an improvement. (See PQgetResult for one example of a place that will loop till it gets something.) I'd be the first to admit that libpq's error handling isn't very good, but I think fixing it will take some wholesale rework of the internal calling conventions, not a few lines of localized patches. Having said that, though, CVS tip does have some progress on this matter; it will usually behave reasonably when it runs out of memory for a query result. If you'd like to pursue the matter, please pull down CVS tip and see what you can do with it. The patch as given would not be much use to us anyway because of the changes since 7.3... regards, tom lane