application hang within RPM library call

Dave Peterson dave_peterson at
Sat Nov 7 21:13:05 UTC 2009


I observe occasional hangs in a C++ application that makes RPM
library calls.  Attaching to the hung process with gdb, I
obtained the following stack trace (manually created by looking
at the assembly code and stack contents, since the application
was compiled without frame pointers):

    [ unknown static function, probably __db_c_cleanup ]
    [ unknown static function, probably dbiGet calling db3cget ]
    [ application code that calls rpmdbNextIterator ]

Is this kind of problem familiar to anyone, or does anyone have
any ideas about what may be causing it?  The platform is RHEL4
x86_64, and the version of RPM is 4.3.3-26_nonptl (from RedHat).
The application is multithreaded but all RPM library calls are
made by a single thread.  The application's use of RPM library
calls is perhaps a bit unusual, and looks essentially like this:

    rpmdb db;
    int result = rpmdbOpen(NULL, &db, O_RDONLY,
                           S_IRUSR | S_IRGRP | S_IROTH);

    if (result)
     { handle error }
     { rpmdbMatchIterator i, j;
       i = rpmdbInitIterator(db, RPMDBI_PACKAGES, NULL, 0);

       // code goes here that may advance iterator i by calling
       // rpmdbNextIterator()

       j = rpmdbInitIterator(db, RPMDBI_PACKAGES, NULL, 0);

       // code goes here that advances i and j independently
       // (according to some complex application-specific logic)
       // by calling rpmdbNextIterator().  When application is
       // finished using a given iterator, it calls
       // rpmdbFreeIterator() on that iterator.


Is it ok to have multiple rpmdbMatchIterator objects opened at
the same time, advancing them independently within a single
thread?  Are there any other potential problems with the code?


More information about the Rpm-list mailing list