RPM Community Forums

Mailing List Message of <rpm-users>

Re: free() pointer error when using bindings to read specfile

From: Jeff Johnson <n3npq@mac.com>
Date: Sun 13 Sep 2009 - 18:50:08 CEST
Message-id: <6C25B792-D166-471A-AD41-D31BE2D87E8E@mac.com>

On Sep 13, 2009, at 12:32 PM, Eric MSP Veith wrote:

> Jeff,
>
> thanks for your help.
>
> Am Sonntag, 13. September 2009 18:08:51 schrieb Jeff Johnson:
>> On Sep 13, 2009, at 11:08 AM, Eric MSP Veith wrote:
>> This error is going to be RPM version specific. All memory is no
>> refcounted with mutexes, and malloc overhead is avoided by resusing
>> items from memory pools. Which is why I'm not able top reproduce on
>> cvs HEAD.
>
> Is that mutex-refcount-thingy already part of 5.2.0?
>

The rpmioPool mechanism is in 5.2.0 yes. But iirc I added the  
refcounts for Spec
and Package since 5.2.0. Not too hard to backport, but because
its refcounts, well, there are often some twisty little details.

You can see what objects are in pools by adding -vv to any CLI  
operation:

[jbj@fedora10 rpmdb]$ rpm -q -vv popt
D: pool fd:	created size 212 limit -1 flags 0
D: pool lua:	created size 32 limit -1 flags 0
D: pool ts:	created size 720 limit -1 flags 0
D: pool gi:	created size 88 limit -1 flags 0
D: pool db:	created size 176 limit -1 flags 0
D: pool dbi:	created size 332 limit -1 flags 0
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
D: opening  db index       /var/lib/rpm/Name rdonly mode=0x0
D: pool mi:	created size 128 limit -1 flags 0
D: pool dig:	created size 236 limit -1 flags 0
D: pool ctx:	created size 56 limit -1 flags 0
D: opening  db index       /var/lib/rpm/Pubkeys rdonly mode=0x0
D: pool h:	created size 216 limit -1 flags 0
D: pool iob:	created size 20 limit -1 flags 0
D: ========== RSA pubkey id 1dc5c758 d22e77f2 (h#1104)
D: rpmdb: read h#    1097 Header V3 RSA/SHA256 signature: OK, key ID  
d22e77f2
popt-1.13-5.fc11.i586
D: pool tsi:	created size 24 limit -1 flags 0
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: pool gi:	reused 0, alloc'd 1, free'd 1 items.
D: pool mi:	reused 0, alloc'd 2, free'd 2 items.
D: pool tsi:	reused 3, alloc'd 1, free'd 1 items.
D: pool ts:	reused 0, alloc'd 1, free'd 1 items.
D: pool db:	reused 0, alloc'd 1, free'd 1 items.
D: pool dbi:	reused 0, alloc'd 3, free'd 3 items.
D: pool h:	reused 1, alloc'd 1, free'd 1 items.
D: pool lua:	reused 0, alloc'd 1, free'd 1 items.
D: pool ctx:	reused 1, alloc'd 2, free'd 2 items.
D: pool iob:	reused 0, alloc'd 1, free'd 1 items.
D: pool dig:	reused 0, alloc'd 1, free'd 1 items.
D: pool fd:	reused 16, alloc'd 2, free'd 2 items.

For you specific problem you want the "spec" and "pkg" pools
for the objects, and perhaps look for "iob" operations
which carry the string store returned through python/perl methods.

>> I still suggest using YAML (or XML if that's your poison). Loading
>> YAML is
>> dirt simple and you end up with native objects (rather than custom
>> crufty
>> getter/setter methods) ready for use.
>
> In that case the Perl bindings wouldn't be bindings anymore but just  
> a set of
> parsing actions around "rpm -q"? I mean, it's pretty simple (if time-
> consuming) to rewrite things.
>

All methods around spec files are just parsing operations, yes.

So only a spewage aesthetic makes sense. Personally, I find YAML
easier on my tired old eyes, all the angle brackets in XML scratch
my cornea.

YAML has been in RPM for years now, XML even longer. So "time-consuming"
is a polite euphemism for "lazy" imho.

But feel free to do whatever you wish. I suggested YAML solely
because it focusses on data, not object getter/setter methods.
The data is the same for all languages even when there are
necessary dialectical differences to use dicts in Python
and ties in Perl, etc, etc, etc.


> Two last things:
>
> 1. The "Requireflags" map to defines I presume, with "12" beeing the
> equivalent of ">=", I guess. I can't find that in the API docs. :-/  
> Can you
> point me on to where to find it?
>

Yes. Its a bit obscure to find however. Here's the only bits within
dependency flags ithat can be relied on (all the other bits can
and will change without notice and so the values cannot be relied upon).

 From <rpmdb/rpmevr.h> (the current location):

     RPMSENSE_LESS       = (1 << 1),
     RPMSENSE_GREATER    = (1 << 2),
     RPMSENSE_EQUAL      = (1 << 3),


> 2. The API docs on rpm5.org are for 4.5. Is that a typo or are they  
> really
> that old? :-)
>

You can "make apidocs" anytime you wish, I do maintain the doxygen  
annotations.

But once the bird has flown the coop, well, what documentation you find
on the web is gone gone gone ...

73 de Jeff
Received on Sun Sep 13 18:50:31 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.