There's a class of problems that are in need of solving
now that miRE items have a refcnt and are re-used from a pool.

The issue is simply adding a "newref" to miRE patterns
when created. Previously, miRE patterns were simply
malloc'd and free'd from the heap where needed.

Now there is a usage mutex attached to miRE patterns that
needs to be incremented/decremented.

Here's one flaw that I just noticed (now that I'm using
/usr/lib/rpm/bin/grep from my PATH):

[jbj@fedora10 src]$ vg !!
vg grep '^---' /tmp/d > /tmp/dd
==13080== Memcheck, a memory error detector.
==13080== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et  
al.
==13080== Using LibVEX rev 1804, a library for dynamic binary  
translation.
==13080== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==13080== Using valgrind-3.3.0, a dynamic binary instrumentation  
framework.
==13080== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et  
al.
==13080== For more details, rerun with: -v
==13080==
==13080== Invalid read of size 4
==13080==    at 0x75DA00: pthread_mutex_lock (in /lib/libpthread-2.9.so)
==13080==    by 0x408E786: yarnPossess (yarn.c:264)
==13080==    by 0x4077A62: rpmioFreePoolItem (rpmmalloc.c:180)
==13080==    by 0x404E44E: mireFreeAll (mire.c:120)
==13080==    by 0x804C15A: main (rpmgrep.c:1583)
==13080==  Address 0xc is not stack'd, malloc'd or (recently) free'd
==13080==
==13080== Process terminating with default action of signal 11 (SIGSEGV)
==13080==  Access not within mapped region at address 0xC
==13080==    at 0x75DA00: pthread_mutex_lock (in /lib/libpthread-2.9.so)
==13080==    by 0x408E786: yarnPossess (yarn.c:264)
==13080==    by 0x4077A62: rpmioFreePoolItem (rpmmalloc.c:180)
==13080==    by 0x404E44E: mireFreeAll (mire.c:120)
==13080==    by 0x804C15A: main (rpmgrep.c:1583)
==13080==

All that's needed to fix is add mire->nrefs++ somewhere.

If you do see a mire problem (proyvind is seeing some with libcpuinfo,
I've got a hack-o-round in place with embedded JS, other obscure code  
paths
are surely affected as well), the diagnosis is add --miredebug to  
display
the locations where mire (or other RPM objects, all pool objects have  
a similar
debugging option) objects are referenced and dereferenced.

Most of the problems will be seen only at program exit during pool  
teardown.

73 de Jeff