From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Olaf Hartmann <hao(at)telemedsys(dot)de> |
Cc: | pgsql-bugs(at)postgresql(dot)org, Sean Chittenden <sean(at)chittenden(dot)org> |
Subject: | Re: libpq3 + ssl memory leak |
Date: | 2003-12-13 01:27:17 |
Message-ID: | 878ylhv762.fsf@mailbox.samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Okay, I've attached a patch that fixes the problem for me. The problem
turned out to be pretty simple: the PostgreSQL code (both backend and
frontend SSL support) was calling SSL_get_peer_certificate() without
properly free'ing its return value.
I haven't actually confirmed the backend memory leak, but it should be
readily reproduceable (the same OpenSSL API call is made and the
return value is never free'd).
Olaf, can you please test the attached patch? (Against CVS HEAD, but
should apply easily enough to 7.4.0) At the very least you'll need to
rebuild libpq and ensure that the test app picks up the new .so, but
testing the backend with the patch applied would also be helpful.
This fix needs to be in 7.4.1, so if anyone wants to review this
patch, that would be great.
-Neil
P.S. I added an assertion in the backend code to help catch any other
memory leaks in this area. I didn't add an equivalent one to the
frontend code, because libpq doesn't seem to be setup for
assertions. When this is applied to 7.4.1, we probably shouldn't
include the assertion at the risk of suffering backend crashes.
Attachment | Content-Type | Size |
---|---|---|
ssl-libpq-mem-leak-1.patch | text/x-patch | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | cnliou | 2003-12-13 04:19:14 | Re: RI within PLPGSQL |
Previous Message | Tom Lane | 2003-12-12 21:01:14 | Re: failed to lookup type 0 |