On Aug 13, 2012, at 11:16 AM, Paul Eggleton <paul.eggle...@linux.intel.com> wrote:
> Hi there, > > Following my previous request for assistance with performing rpm db queries > from C with rpm 5.4.9 (thanks for the help with that!), I put together the > following utility: > > http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/rpm/rpmresolve/rpmresolve.c > todo++: will look in a moment. > This consolidates a couple of the operations we used to do with multiple > invocations of rpm, and improved performance of those operations as a > result. I'd definitely appreciate any suggestions for improvements to the > code though as I am still a novice when it comes to using the RPM libraries. > (I could probably be doing better error checking for a few of the calls, I'm > already aware of that.) > > However, we are experiencing an intermittent problem apparently now brought > to the surface with this utility - an assertion failure when opening the > database: > > | rpmresolve: dbconfig.c:493: db3New: Assertion `dbOpts != ((void *)0) && > *dbOpts != '\0'' failed. > This failure (usually) occurs when /usr/lib/rpm/macros wasn't read, usually because of CLI overrides in a host <-> target environment. There's another (possible but unlikely) failure if there is an access of a non-defined tag used in an index. Use gdb and see what value is in "tag" here. Alternatively, you can wrap %trace…%trace (%trace is a toggle) or add %dump... (%dump will spew all defined macros) to the specific macro expansion. > Unfortunately the problem does not occur every time and so far we have not > been able to reproduce it outside our build environment; we did however > see this error previously with rpm itself, just not as frequently as we are > now. It seems that it is a result of the dbi_config macro being unset or > otherwise resolving to empty string / null, but as far as I can tell this > macro is set as part of the main rpm macros file so I can't see how it > could not be set. I notice the same assertion failure in the following report > but there was no further information to suggest why it occurred there: Hmmmm … dunno why intermittent: this code (and the assert) is traversed on every table open. > > http://marc.info/?l=rpm-devel&m=126175013622633 > There are problem in perl bindings with finding modules: one MUST install (circa 2009, ~fixed now to run in tree) the CPAN module in order to run tests. Issues with bindings are from unusual code paths that fail to read necessary configuration (for whatever reason). > Does anyone have any clues as to how this failure could come about? > hth 73 de Jeff > Thanks, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-devel@rpm5.org ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
