On Jan 26, 2010, at 5:26 AM, Bernhard Rosenkränzer wrote:

> Possibly caused by a slightly corrupted rpmdb, it has gone through its
> share of updates to HEAD snapshots...
> 
> Starting program: /bin/rpm -e kdepim
> [Thread debugging using libthread_db enabled]
> Freeing read locks for locker 0x21: 1542/140325654452096
> Freeing read locks for locker 0x23: 1542/140325654452096
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> Freeing mutex for process: 1542/0
> 
> Program received signal SIGSEGV, Segmentation fault.
> rpmbfChk (bf=0x0, _s=0x689750, ns=<value optimized out>) at rpmbf.c:98
> 98	    for (ns = 0; ns < bf->k; ns++) {
> #0  rpmbfChk (bf=0x0, _s=0x689750, ns=<value optimized out>) at rpmbf.c:98
> #1  0x00007ffff794b70e in addRelation (ts=0x650c20, p=0x65d7a0, 
>    selected=<value optimized out>, requires=0x65e1b0) at depends.c:2149
> #2  0x00007ffff794be09 in rpmtsOrder (ts=0x650c20) at depends.c:2432
> #3  0x00007ffff7975806 in rpmcliInstallOrder (ts=0xcf1a1ff5)
>    at rpminstall.c:320
> #4  0x00007ffff7975aff in rpmErase (ts=0x650c20, ia=0x7ffff7b97ea0, 
>    argv=<value optimized out>) at rpminstall.c:797
> #5  0x0000000000404a4a in main (argc=<value optimized out>, 
>    argv=<value optimized out>) at ./rpmqv.c:905
> 

Ah yes.

The context of the segfault is trying to add an element to a Bloom filter.

The parameters used for instantiating the Bloom filter derived from
package/transaction content are causing bf to be NULL leading to a
segfault from traversing a NULL pointer.

I can likely guess what needs to be done, but it would help if you
could send along the -vv spewage so I can confirm my guess.

I expect to see something like an attempt to erase a package with
no files, or perhaps a pure erasure, with the parameters needed
for initializing the Bloom filter are tuned towards an upgrade
rather than a pure erasure.

Does that sound like what you were attempting?

But I'll get a patch in place to ensure that the Bloom filter
has a minimum population estimate of, say 4K, and/or add another
lazy rpmbfNew() on a pure erasure path, today.

73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org