Bug#392927: Spfmilter dies unexpectedly with SIGABRT
On Sat, Nov 17, 2007 at 04:23:26PM +0200, Mattias Nordstrom [EMAIL PROTECTED] wrote: Ok, so just to be on the clear, an update that would include the three line patch on main.c fixes the problem in question? It appears so; that's the only difference between 0.999-1.0.0-p3-3 and what I'm running on my backup MX. -- Mike Markley [EMAIL PROTECTED] As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. - Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
Ok, so just to be on the clear, an update that would include the three line patch on main.c fixes the problem in question? Regards, Mattias Mike Markley wrote: I've been running the patches suggested in here since July on my backup MX without any evidence of problems. In fact, spfmilter's memory footprint has not budged since I began doing so. On the other hand, I'm replacing that server with a new one that just got a fresh etch install. spfmilter crashes pretty much daily. If the libspf maintainer is listening in, is there any chance we can get this bundled up for proposed-updates? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
I've been running the patches suggested in here since July on my backup MX without any evidence of problems. In fact, spfmilter's memory footprint has not budged since I began doing so. On the other hand, I'm replacing that server with a new one that just got a fresh etch install. spfmilter crashes pretty much daily. If the libspf maintainer is listening in, is there any chance we can get this bundled up for proposed-updates? -- Mike Markley [EMAIL PROTECTED] Support your country all the time and your government when it deserves it. - Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
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 +, [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.0 +
+++ main.c 2007-07-25 10:20:01.0 +
@@ -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]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
On Thu, Jul 19, 2007 at 03:36:27PM -0700, Mike Markley [EMAIL PROTECTED] wrote: On Fri, Jul 13, 2007 at 04:26:08PM +, [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. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
On Fri, Jul 13, 2007 at 04:26:08PM +, [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. -- Mike Markley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
yes, looks like this is happening in SPF_smtp_from() and it is the double free that aaron reports in #315196. it is hard to be sure about the earlier report in that bug, if that is a different author. I have a version of this built some time back against a libspf version slightly before the comment that Herbert quotes, which doesn't suffer from this problem, I'll look at the diff. probably this bug should be filed against the libspf0 library. as far as I understand it neither of this or the libspf2 libs are supported upstream, and they probably have more subtle bugs in their implementation of SPF. I suggest interested users look at the archives of, or ask on the spf mailing lists. nevertheless, I've had some good use out of my build of this with sarge, and would like to see this bug fixed since this package is in etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392927: Spfmilter dies unexpectedly with SIGABRT
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. Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
