Re: libspf2 crash

On Wed, May 07, 2008 at 10:44:46AM -0500, Ladar Levison wrote:
> 
> I'm seeing a number of segfaults. I believe the issue is that libreplace is 
> calling __dn_skipname with identical pointers, but I can't seem to narrow it 
> down. When I pull up a core dump, it looks like:
> 
> (gdb) bt
> #0  0x00be37a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x00c24815 in raise () from /lib/tls/libc.so.6
> #2  0x00c26279 in abort () from /lib/tls/libc.so.6
> #3  0x08065610 in segfault_handler (received_signal=11) at common/signals.c:36
> #4  <signal handler called>
> #5  0x00db2e88 in __ns_name_skip () from /lib/libresolv.so.2
> #6  0x00dac2dc in __dn_skipname () from /lib/libresolv.so.2
> #7  0x00662205 in __ns_skiprr (ptr=0xa0cdd2 "", eom=0xa0cdd2 "", 
> section=ns_s_an, count=10526448) at __ns_initparse.c:84

If "count" is not a call by reference parameter its value represents
probably an address (0xA09EF0) instead a count value?
But this could be just a limitation of gdb's knowledge of the calling
interface ...

> #8  0x0066237e in __ns_initparse (msg=0xa0a866 "ý\f", msglen=9618, 
> handle=0xa0a810) at __ns_initparse.c:124
> #9  0x0065ba19 in SPF_dns_resolv_lookup (spf_dns_server=0xaba4ae8, 
> domain=0xb78f28e0 "yourshirevillage.com", rr_type=ns_t_mx, should_cache=1) at 
> spf_dns_resolv.c:188

I'm not sure if my experience I had so far matches this problem somehow:

I encountered a problem of libspf2 1.2.5 which does not cleanly
initialize a data structure given to res_ninit().

Maybe this leads to a delayed problem like the above (I think not very
likely, because __ns_initparse is called after res_ninit() ...). Anyway,
just to mention it: In my environment res_ninit() takes the workspace
given and tries to free up referenced memory - asuming a reused
workspace. If the malloced workspace is not initialized to zero
res_ninit() tries to free garbage ... (seen on Solaris 8/Sparc,
Solaris 9/x86, not on Linux so far).
(http://jk.kom.tuwien.ac.at/software/milter-greylist/libspf2-1.2.5-res_ninit.patch)

A second point is the sometime missing malloc result handling in libspf2
1.2.5 On serveral occasions it is not expected that malloc may return a
NULL pointer ... 
(http://jk.kom.tuwien.ac.at/software/milter-greylist/libspf2-1.2.5-malloc.patch). 
However, this should only a problem if the virtual memory gets really
short ;)

Johann