bogofilter-static-1.0.0-1 RPM problem (CentOS 3.6)

[Matthias Andree]

On Fri, 23 Dec 2005, David Relson wrote:

> I've been corresponding with Al for over a week now.  His first message started with:
> 
> : I've downloaded bogofilter-1.0.0-1.i586.rpm and it runs fine on a Fedora 
> :  Core 3 (Celeron).  The RPM installs on a Red Hat 9 system (AMD Duron), 
> : but bogofilter dumps core.  Don't have a debugger on that machine, so 
> : not sure why.  Both machines show up as i686 (uname -m), which leaves me 
> : wondering if it is CPU issue since the RPM is i586.rpm.
> 
> For bogofilter to have problems on Red Hat 9 seems like something
> important with which to deal!  Even though RH9 isn't what I use, it is
> one of the major distributions.

Red Hat is a major distribution, and it's an expensive enterprise-grade
distribution, actually RHEL. The free-of-charge versions were moved into
the Fedora project and are now called Fedora Linux.

Red Hat have the funds to rebuild bogofilter from our .src.rpm, and if
they want some small thing changed in bogofilter to ease their packaging
or otherwise improve the user experience, I'm all for it. Time
permitting, I'll try to rpmbuild --rebuild bogofilter-1.0.0-1.src.rpm on
some systems that I have access to, to learn if there's anything waiting
to catch someone.

If it's just an experiment to narrow down the failing cases, well,
please accept my apologies for the fuss and my misunderstanding everyone.

> In any case, Al shifted to bogofilter-static in an attempt to lessen
> BerkeleyDB dependencies.  The problem remains the same, though he and I
> have learned a bit more:
> 
>   With /etc/bogofilter.cf containing 1 line:
>   
>       bogofilter_dir=/root/bogofilter/testcore
> 
>   and running in directory /root/bogofilter/testcore (which is empty,
>   except for the output of a prior "bogoutil -d" run), command 
> 
>     bogoutil -l wordlist.db < wordlist
> 
>   produces a SIGSEGV, while command 
> 
>     bogoutil -C -l wordlist.db < wordlist
> 
>   works fine.
> 
> 
>   I can't recall ever seeing a problem like this when populating a new
> wordlist using bogoutil.  Bogoutil has been reliable and robust, no?

As far as I can tell, yes. We need to find out what about that
configuration line causes the trouble, perhaps with valgrind.

> With only a single process involved, threading issues seem improbable. 

Unfortunately, I have to disagree. The problem is that the Berkeley DB
library, no matter if linked as shared or static object, is deeply
interwoven with the kernel, and it is not a coincidence that the SUSE
db42 RPM installs two versions of the library, one in TLS, with
different contents. This allows for picking the proper CPU-dependent
library at run-time. Using a static library forfeits this distinction.

The locking code is unaware if there's only a single process or if there
are several, Berkeley DB will place the mutexes nonetheless IIRC.

> > Now that we've had the _static packages in 1.0.0, every future 1.0.X
> > version will have to offer them for compatibility, but we cannot
> > possibly guarantee that it works on every system.
> 
> My recollection is that we created the static rpms for 2 reasons:
> people without build privileges and people with borked BerkeleyDB
> versions.

Why would people without build privileges be allowed to install RPMs?
I don't recall borked Berkeley DB versions, only systems that did not
have the RPMs for the right version of the binary RPM. And now we need
to figure if we have genuine bugs in bogofilter or if the Mandrake
libdb.a file is useless on some of the other systems.

-- 
Matthias Andree