On Tue, Jul 24, 2007 at 03:03:13PM -0700, Mike Markley wrote:
> On Thu, Jul 19, 2007 at 03:36:27PM -0700, Mike Markley <[EMAIL PROTECTED]>
> wrote:
> > On Fri, Jul 13, 2007 at 04:26:08PM +0000, [EMAIL PROTECTED] <[EMAIL
> > PROTECTED]> wrote:
> > > commenting out the three xfree()s after the referenced comment stops
> > > the crash. I couldn't say whether spfmilter will then leak in the
> > > way that the comment warns ofi (I suspect not), but that would be a
> > > less severe bug in my book. I will feedback when I know more about
> > > that question.
> > >
> > > scary though it may sound, please consider applying this to libspf0,
> > > and putting the resulting package(s) forward for the next point release
> > > of etch.
> >
> > I've applied this patch on one of my etch boxes that often experiences
> > this crash. It's quite memory-contrained, so any memory leaks should
> > also be reasonably obvious. I'll report results as I get them.
>
> I've been running this for nearly a week on my medium-volume backup MX,
> and if there's a memory leak, it's a very slow one. My baseline
> (off-peak) vsize for spfmilter started out as 10340 on 7/20 and then
> increased to 10396 on 7/21 and to 10460 on 7/23. Nonetheless, it does
> appear to be leaking. I can't actually prove that it's libspf0 leaking,
> though, since I'm not stable enough without the patch to take any real
> measurements.
>
> According to my etch system, whitelister is the only other package using
> libspf0. It's probably worth getting in touch with its maintainer to get
> his take.
yes, and wnpp recently said ...
>The following packages have been orphaned:
>
> libspf (#433108), orphaned 5 days ago
> Description: the ANSI C SPF reference library
> Reverse Depends: libspf-dev spfmilter spfqtool whitelister
> Installations reported by Popcon: 203
If I have understood the relative state of maintenance of libspf0 and
libspf2 then the right thing to do long-term is to get packages still
depending on libspf0 across onto libspf2, but in the short term an
upload of libspf0 to straighten this out sounds like a good idea.
the bug in libspf appears to be the freeing of p->current_domain and
p->original_domain when they point to the same place (I am triggering
this repeatably using an @gmail.com MAIL FROM for testing, but I
haven't look deep enough to say what is required).
the following patch, which mimics the other place where these are freed,
would seem to be what the author intended.
--- main.c.orig 2007-07-25 10:26:40.000000000 +0000
+++ main.c 2007-07-25 10:20:01.000000000 +0000
@@ -1683,7 +1683,8 @@
xfree(p->from);
}
- if (p->spf_rlevel > 0)
+ if ((p->spf_rlevel > 0) &&
+ (p->current_domain != p->original_domain))
{
xfree(p->current_domain);
}
I recall now that I looked at using this version of libspf0, and
specifically this bug, when I built myself an spfmilter for sarge,
and at the time I decided I'd rather stick with the version that
was in sarge :-(
I would guess that spfqtool would not suffer from this, but that
whitelister, being a similar sort of thing may. On postfix I mostly
see recommendations for other implementations, so it may be that it,
like spfmilter, is little used in debian ?
Regards,
Paddy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
