Milter-greylist

Matt Kettler wrote:
> I just tried to run milter-greylist 3.0rc6 on my machine and it segfaults while
> loading the configuration.
> 
> I trapped it in gdb, and did a backtrace of the stack:
> 
> #0  0x4015b54c in memcpy () from /lib/i686/libc.so.6
> #1  0x40019c73 in memcpy () from /lib/libsafe.so.2
> #2  0x0804db4d in ipfromstring (str=0x8090deb "127.0.0.0", sa=0x8087c80,
>     salen=0xbffc8678, family=16) at pending.c:600
> #3  0x08052a2d in conf_lex () at conf_lex.l:179
> #4  0x0805253e in conf_parse () at bison.simple:573
> #5  0x08054895 in conf_load () at conf.c:152
> #6  0x0804b5e4 in main (argc=1, argv=0xbffff9d4) at milter-greylist.c:886
> #7  0x400f4a67 in __libc_start_main () from /lib/i686/libc.so.6
> 
> 
> It looks like it blew up trying to parse a like containing 127.0.0.0.

Ok, upon further testing, it stops blowing up if I build with ./configure.

Only when I use: "--enable-dnsrbl  --with-libbind=/usr/lib/" does it blow up.
That suggests that my build of libbind isn't thread safe.

I tried adding --enable-threads to the configure for bind, rebuilt/reinistalled
libbind (strangely only libbind.a changed, the .so had the same md5sum as the
old one. Yes I did make clean first.. so it did rebuild it.). No help.

This is the configure I'm using in bind 9.2.1:

/configure --with-libtool --enable-libbind --enable-threads
--with-randomdev=/dev/random

(and yes, I'm correctly moving libbind.* from /usr/local/lib to /usr/lib where
ld will find them)


Any suggestions?

At Fri, 27 Oct 2006 20:27:27 -0400,
Matt Kettler wrote:
> 
> Matt Kettler wrote:
> > I just tried to run milter-greylist 3.0rc6 on my machine and it segfaults while
> > loading the configuration.
> > 
> > I trapped it in gdb, and did a backtrace of the stack:
> > 
> > #0  0x4015b54c in memcpy () from /lib/i686/libc.so.6
> > #1  0x40019c73 in memcpy () from /lib/libsafe.so.2
> > #2  0x0804db4d in ipfromstring (str=0x8090deb "127.0.0.0", sa=0x8087c80,
> >     salen=0xbffc8678, family=16) at pending.c:600
> > #3  0x08052a2d in conf_lex () at conf_lex.l:179
> > #4  0x0805253e in conf_parse () at bison.simple:573
> > #5  0x08054895 in conf_load () at conf.c:152
> > #6  0x0804b5e4 in main (argc=1, argv=0xbffff9d4) at milter-greylist.c:886
> > #7  0x400f4a67 in __libc_start_main () from /lib/i686/libc.so.6
> > 
> > 
> > It looks like it blew up trying to parse a like containing 127.0.0.0.

It is not a thread problem. I can't tell the exact reason, but it looks
a binary incompatibility between libc and libbind. Especially, struct
addrinfo is suspicious.
* Make sure to include BIND's headers rather than system headers.
* If it does not work or breaks another thing, undefine
HAVE_GETADDRINFO in your config.h.

> Ok, upon further testing, it stops blowing up if I build with ./configure.
> 
> Only when I use: "--enable-dnsrbl  --with-libbind=/usr/lib/" does it blow up.
> That suggests that my build of libbind isn't thread safe.

I think --with-libbind=/usr/local is appropreate here.

> I tried adding --enable-threads to the configure for bind, rebuilt/reinistalled
> libbind (strangely only libbind.a changed, the .so had the same md5sum as the
> old one. Yes I did make clean first.. so it did rebuild it.). No help.

It is intentional design. BIND guys do not hope existing programs
link spontaneously new libbind spontaneously.

> This is the configure I'm using in bind 9.2.1:
> 
> /configure --with-libtool --enable-libbind --enable-threads
> --with-randomdev=/dev/random
> 
> (and yes, I'm correctly moving libbind.* from /usr/local/lib to /usr/lib where
> ld will find them)

It looks dangerous. It may lead ABI crashes between /usr/include/*.h
and /usr/lib/libbind.a.

AIDA Shinra wrote:
> At Fri, 27 Oct 2006 20:27:27 -0400,
>> Ok, upon further testing, it stops blowing up if I build with ./configure.
>>
>> Only when I use: "--enable-dnsrbl  --with-libbind=/usr/lib/" does it blow up.
>> That suggests that my build of libbind isn't thread safe.
> 
> I think --with-libbind=/usr/local is appropreate here.

OK.

> 
>> I tried adding --enable-threads to the configure for bind, rebuilt/reinistalled
>> libbind (strangely only libbind.a changed, the .so had the same md5sum as the
>> old one. Yes I did make clean first.. so it did rebuild it.). No help.
> 
> It is intentional design. BIND guys do not hope existing programs
> link spontaneously new libbind spontaneously.
> 
>> This is the configure I'm using in bind 9.2.1:
>>
>> /configure --with-libtool --enable-libbind --enable-threads
>> --with-randomdev=/dev/random
>>
>> (and yes, I'm correctly moving libbind.* from /usr/local/lib to /usr/lib where
>> ld will find them)
> 
> It looks dangerous. It may lead ABI crashes between /usr/include/*.h
> and /usr/lib/libbind.a.
> 


Ok, so I did the following:

1) removed libbind.* from /usr/lib/, leaving them in /usr/local/lib/ where binds
build process put them.

2) modified /etc/ld.so.conf to include /usr/local/lib, and ran ldconfig to build
the cache.

3) rebuilt milter-greylist:
	 ./configure --enable-dnsrbl  --with-libbind=/usr/local/lib/
	make clean
	make
	
Still crashes, same way.

(gdb) run
Starting program: /home/mkettler/milter-greylist-3.0rc6/milter-greylist
[New Thread 16384 (LWP 3760)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3760)]
0x4015b54c in memcpy () from /lib/i686/libc.so.6
(gdb) bt
#0  0x4015b54c in memcpy () from /lib/i686/libc.so.6
#1  0x40019c73 in memcpy () from /lib/libsafe.so.2
#2  0x0804db4d in ipfromstring (str=0x8090deb "127.0.0.0", sa=0x8087c80,
    salen=0xbffc7b28, family=16) at pending.c:600
#3  0x08052a2d in conf_lex () at conf_lex.l:179
#4  0x0805253e in conf_parse () at bison.simple:573
#5  0x08054895 in conf_load () at conf.c:152
#6  0x0804b5e4 in main (argc=1, argv=0xbfffee84) at milter-greylist.c:886
#7  0x400f4a67 in __libc_start_main () from /lib/i686/libc.so.6


Any suggestions?

At Wed, 01 Nov 2006 19:32:13 -0500,
Matt Kettler wrote:
> 
> AIDA Shinra wrote:
> > At Fri, 27 Oct 2006 20:27:27 -0400,
> >> Ok, upon further testing, it stops blowing up if I build with ./configure.
> >>
> >> Only when I use: "--enable-dnsrbl  --with-libbind=/usr/lib/" does it blow up.
> >> That suggests that my build of libbind isn't thread safe.
> > 
> > I think --with-libbind=/usr/local is appropreate here.
> 
> OK.
> 
> > 
> >> I tried adding --enable-threads to the configure for bind, rebuilt/reinistalled
> >> libbind (strangely only libbind.a changed, the .so had the same md5sum as the
> >> old one. Yes I did make clean first.. so it did rebuild it.). No help.
> > 
> > It is intentional design. BIND guys do not hope existing programs
> > link spontaneously new libbind spontaneously.
> > 
> >> This is the configure I'm using in bind 9.2.1:
> >>
> >> /configure --with-libtool --enable-libbind --enable-threads
> >> --with-randomdev=/dev/random
> >>
> >> (and yes, I'm correctly moving libbind.* from /usr/local/lib to /usr/lib where
> >> ld will find them)
> > 
> > It looks dangerous. It may lead ABI crashes between /usr/include/*.h
> > and /usr/lib/libbind.a.
> > 
> 
> 
> Ok, so I did the following:
> 
> 1) removed libbind.* from /usr/lib/, leaving them in /usr/local/lib/ where binds
> build process put them.

BIND may put headers and libraries at /usr/local/bind/{include,lib} in
some situation. Are you sure libbind.a was at /usr/local/lib and
headers were at /usr/local/include?

> 2) modified /etc/ld.so.conf to include /usr/local/lib, and ran ldconfig to build
> the cache.

The libbind.a is a static library. No need for ldconfig.

> 3) rebuilt milter-greylist:
> 	 ./configure --enable-dnsrbl  --with-libbind=/usr/local/lib/
> 	make clean
> 	make
> 	
> Still crashes, same way.

Don't addappend /lib/ after --with-libbind=/usr/local.

Then tell me your make log and the result of "ldd milter-greylist".

AIDA Shinra wrote:
> At Wed, 01 Nov 2006 19:32:13 -0500,
> Matt Kettler wrote:
> 
>> 2) modified /etc/ld.so.conf to include /usr/local/lib, and ran ldconfig to build
>> the cache.
> 
> The libbind.a is a static library. No need for ldconfig.

It's not using libbind.a, it's using the .so version, hence the ldconfig. (see
ldd output below)


> 
>> 3) rebuilt milter-greylist:
>> 	 ./configure --enable-dnsrbl  --with-libbind=/usr/local/lib/
>> 	make clean
>> 	make
>> 	
>> Still crashes, same way.
> 
> Don't addappend /lib/ after --with-libbind=/usr/local.

Fair enough, fixed.

./configure --enable-dnsrbl  --with-libbind=/usr/local

> 
> Then tell me your make log and the result of "ldd milter-greylist".
> 

(See the attached make.log, but these two messages went to stderr.)

$ make >make.log
conf_lex.c:2349: warning: `yy_flex_realloc' defined but not used
dump_lex.c:1678: warning: `yy_flex_realloc' defined but not used
$

Here's your ldd:

$ ldd milter-greylist
        /lib/libsafe.so.2 => /lib/libsafe.so.2 (0x40018000)
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40028000)
        libbind.so.0 => /usr/local/lib/libbind.so.0 (0x40078000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x400b8000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x400ca000)
        libc.so.6 => /lib/i686/libc.so.6 (0x400df000)
        libdl.so.2 => /lib/libdl.so.2 (0x40218000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$

Still has the same blow-up:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9707)]
0x4015b54c in memcpy () from /lib/i686/libc.so.6
(gdb) bt
#0  0x4015b54c in memcpy () from /lib/i686/libc.so.6
#1  0x40019c73 in memcpy () from /lib/libsafe.so.2
#2  0x0804db4d in ipfromstring (str=0x8090deb "127.0.0.0", sa=0x8087c80,
salen=0xbffc8048, family=16) at pending.c:600
#3  0x08052a2d in conf_lex () at conf_lex.l:179
#4  0x0805253e in conf_parse () at bison.simple:573
#5  0x08054895 in conf_load () at conf.c:152
#6  0x0804b5e4 in main (argc=1, argv=0xbffff3a4) at milter-greylist.c:886
#7  0x400f4a67 in __libc_start_main () from /lib/i686/libc.so.6

At Thu, 02 Nov 2006 11:09:03 -0500,
Matt Kettler wrote:
> 
> AIDA Shinra wrote:
> > At Wed, 01 Nov 2006 19:32:13 -0500,
> > Matt Kettler wrote:
> > 
> >> 2) modified /etc/ld.so.conf to include /usr/local/lib, and ran ldconfig to build
> >> the cache.
> > 
> > The libbind.a is a static library. No need for ldconfig.
> 
> It's not using libbind.a, it's using the .so version, hence the ldconfig. (see
> ldd output below)
> 
> 
> > 
> >> 3) rebuilt milter-greylist:
> >> 	 ./configure --enable-dnsrbl  --with-libbind=/usr/local/lib/
> >> 	make clean
> >> 	make
> >> 	
> >> Still crashes, same way.
> > 
> > Don't addappend /lib/ after --with-libbind=/usr/local.
> 
> Fair enough, fixed.
> 
> ./configure --enable-dnsrbl  --with-libbind=/usr/local
> 
> > 
> > Then tell me your make log and the result of "ldd milter-greylist".
> > 
> 
> (See the attached make.log, but these two messages went to stderr.)
> 
> $ make >make.log
> conf_lex.c:2349: warning: `yy_flex_realloc' defined but not used
> dump_lex.c:1678: warning: `yy_flex_realloc' defined but not used
> $
> 
> Here's your ldd:
> 
> $ ldd milter-greylist
>         /lib/libsafe.so.2 => /lib/libsafe.so.2 (0x40018000)
>         libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40028000)
>         libbind.so.0 => /usr/local/lib/libbind.so.0 (0x40078000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x400b8000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0x400ca000)
>         libc.so.6 => /lib/i686/libc.so.6 (0x400df000)
>         libdl.so.2 => /lib/libdl.so.2 (0x40218000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

1. What happens if you modify LIBS in Makefile like this:
LIBS= -lmilter -lbind -lnsl -pthread

2. Where did BIND installed its headers, especially netdb.h?

3. If everything fails, undefine HAVE_GETADDRINFO in your config.h.
It is a pseudofix but it probably works for you.

AIDA Shinra wrote:
> 1. What happens if you modify LIBS in Makefile like this:
> LIBS= -lmilter -lbind -lnsl -pthread

Same effect.

> 
> 2. Where did BIND installed its headers, especially netdb.h?

bind installed to /usr/local/bind/include. However, there are several netdb.h's
on my system:

/usr/include/bits/netdb.h
/usr/include/netdb.h
/usr/include/rpc/netdb.h
/usr/include/isc/netdb.h
/usr/include/lwres/netdb.h
/usr/local/bind/include/netdb.h

Of importance: my system does have redahat 9's bind-devel package installed, but
it lacks libbind.a and libbind.so. I built my own libbind from redhat's own bind
sourcefiles.

Since I built from the same source, I would have assumed this libbind would work
with everything else redhat shipped.


> 3. If everything fails, undefine HAVE_GETADDRINFO in your config.h.
> It is a pseudofix but it probably works for you.

That does work.


Should I try removing bind-devel? Perhaps its getting mixed pieces somewhere?

Matt Kettler wrote:
> 2. Where did BIND installed its headers, especially netdb.h?
> 
> bind installed to /usr/local/bind/include. However, there are several netdb.h's
> on my system:
> 
> /usr/include/bits/netdb.h
> /usr/include/netdb.h
> /usr/include/rpc/netdb.h
> /usr/include/isc/netdb.h
> /usr/include/lwres/netdb.h
> /usr/local/bind/include/netdb.h
> 
> Of importance: my system does have redahat 9's bind-devel package installed, but
> it lacks libbind.a and libbind.so. I built my own libbind from redhat's own bind
> sourcefiles.

<snip>
> 
> Should I try removing bind-devel? Perhaps its getting mixed pieces somewhere?

Followup:

removing bind-devel didn't help, but it did remove /usr/include/isc/netdb.h and
/usr/include/lwres.netdb.h.

I was able to make it work correctly by editing milter-greylist.h and forcing
netdb.h to be loaded from /usr/local/bind/include/

This works even with   HAVE_GETADDRINFO defined.

So it looks like glibc's /usr/include/netdb.h is not compatible with bind's own
netdb.h.