With many thanks to Connie Sieh, it appears we found the cause of this odd error.  

The trace she suggested helped us find where the yum process was failing.  We then worked our way down to what appears to be a non-compatible 'libsqlite3.so.0'.  The traces showed that we were loading this library out of /usr/local/lib.  When I set and export an LD_LIBRARY_PATH variable to access '/usr/lib64/', yum picked up a different libsqlite3.so.0 file and it runs without error and without chewing up memory.

I will still need to investigate how we got into this situation of a library that's not compatible with our kernel and the yum code.  But at least the yum software is working by setting this environment variable in the shell where I am using yum.

Thanks to all who offered questions and suggestions.

Ken S.

On Dec 20, 2010, at 4:59 PM, Connie Sieh wrote:

> On Mon, 20 Dec 2010, Ken Schumacher wrote:
> 
>> Alan,
>> 
>> Thank you for that pointer.  I re-ran the 'yum clean all' including the --enablerepo='*' option.  It appeared to clean out the same metadata and cache files as last time.  And when I tried the 'yum -d 5 list yum' command again, it still ends up in the loop consuming memory as before.
>> 
>> I appreciate that you added new information that got me to go past an assumption that I had made.  But the problem still persists.
> 
> Please send in private email to me the contents of /tmp/yumtrace
> 
>  strace -fo /tmp/yumtrace yum list yum
> 
> on both a system where it "fails" and one where it "works".
> 
> You may have to install strace which is in the strace rpm.
> 
> -connie sieh

==============================================================
Ken Schumacher  <[log in to unmask]>  (o) 630-840-4579 (f) 630-840-3109
Computing Div/HPC  LQCD Group   Loc: WH8E   http://www.usqcd.org/fnal/
Fermi National Accelerator Lab; PO Box 500 MS 120 Batavia, IL 60510-0500