Re: RPM Libraries Crash in our custom library
Thanks very much for you suggestion . Although we are using headerLink in our code ,the problem seems to be the way we are calling it .In our code we are looking for hdrVec, a globally exported virtual function table and finding the functions we need by absolute offset. This is working till rpm 4.4 ,because this way is not exposed for later versions and we can call the method directly, we have made corresponding changes in our code . After handling this scenario things seems to be working fine and our basic test case results are positive. Thanks for the help . Thanks, DP Rajasekhar On Thu, Jun 14, 2012 at 5:24 PM, Jeffrey Johnson n3...@me.com wrote: On Jun 14, 2012, at 6:49 AM, Rajasekhar wrote: The rpm version we are using is 4.8 and platform is RHEL6 and the valgrind output is attached. This issue we are observing only we have two kernels already installed already on the machine and with one kernel the transaction going just fine . This is where the problem is: ==21323== 1 errors in context 2 of 214: ==21323== Invalid read of size 8 ==21323== at 0x33222177FA: findEntry (header.c:706) ==21323== by 0x3322219BB2: intGetTdEntry (header.c:1300) ==21323== by 0x33222175BA: headerGet (header.c:1337) ==21323== by 0x4C488E3: headerGetEntryWrapper (rc-rpmman.c:3302) ==21323== by 0x4C495E8: rc_rpmman_read_header (rc-rpmman.c:1882) ==21323== by 0x4C4C10D: rc_rpmman_query (rc-rpmman.c:2321) ==21323== by 0x4C4DEE6: rc_rpmman_transact (rc-rpmman.c:1333) ==21323== by 0x4033ED: ??? (in /opt/novell/zenworks/lib/zmd/transact) ==21323== by 0x4038E2: main (in /opt/novell/zenworks/lib/zmd/transact) ==21323== Address 0x507cf98 is 8 bytes inside a block of size 40 free'd ==21323== at 0x4A04D72: free (vg_replace_malloc.c:325) ==21323== by 0x3322618438: rfree (rpmmalloc.c:78) ==21323== by 0x332221DC83: miFreeHeader (rpmdb.c:1541) ==21323== by 0x332221E9AD: rpmdbNextIterator (rpmdb.c:2064) ==21323== by 0x4C4BC59: rc_rpmman_find_system_headers (rc-rpmman.c:713) - ==21323== by 0x4C4C0C6: rc_rpmman_query (rc-rpmman.c:2312) ==21323== by 0x4C4DEE6: rc_rpmman_transact (rc-rpmman.c:1333) ==21323== by 0x4033ED: ??? (in /opt/novell/zenworks/lib/zmd/transact) ==21323== by 0x4038E2: main (in /opt/novell/zenworks/lib/zmd/transact) The Header object returned from rpmdbNextIterator is refcounted data. You are (likely, I can't see the code) using the header object outside the scope of an iterator. Make sure that you do something like myheader = headerLink(h); if you want to use a header outside of the scope of an iterator. You walso need to release the reference somewhere (void) headerFree(myheader); or you WILL have a memory leak. Note that all data retrieved through headerGet() implicitly relies on the reference count of the underlying header: the pointers to header tag data are all within the header object. hth 73 de Jeff __ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM Libraries Crash in our custom library
On Jun 19, 2012, at 12:04 PM, Rajasekhar wrote: Thanks very much for you suggestion . Although we are using headerLink in our code ,the problem seems to be the way we are calling it .In our code we are looking for hdrVec, a globally exported virtual function table and finding the functions we need by absolute offset. This is working till rpm 4.4 ,because this way is not exposed for later versions and we can call the method directly, we have made corresponding changes in our code . After handling this scenario things seems to be working fine and our basic test case results are positive. Good. Thanks for the help . np. If you are attempting dlopen(3) across all possible versions of rpm libraries, you are _SURE_ to run into surprises: there's just too many versions of rpmlib hacked up without clue by Linux vendors for the otherwise sane portable idea of using headerGet() from the system libraries for all possible versions. One way of avoiding *ahem* issues is to steal some copy of headerGet() and headerLoad() to handle metadata blob's. Its also not impossibly hard to steal a copy of rpmdb.c/db3.c and strip that down to just what you need in RedCarpet (since most of the routines and API/ABI in RPM libraries are mostly useless for an add-on installer like RedCarpet). Historically there have been many issues with RedCarpet and -lrpmlib that ultimately rate a reflection of two applications trying to solve the same installation problem differently. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM Libraries Crash in our custom library
On Jun 14, 2012, at 6:49 AM, Rajasekhar wrote: The rpm version we are using is 4.8 and platform is RHEL6 and the valgrind output is attached. This issue we are observing only we have two kernels already installed already on the machine and with one kernel the transaction going just fine . This is where the problem is: ==21323== 1 errors in context 2 of 214: ==21323== Invalid read of size 8 ==21323==at 0x33222177FA: findEntry (header.c:706) ==21323==by 0x3322219BB2: intGetTdEntry (header.c:1300) ==21323==by 0x33222175BA: headerGet (header.c:1337) ==21323==by 0x4C488E3: headerGetEntryWrapper (rc-rpmman.c:3302) ==21323==by 0x4C495E8: rc_rpmman_read_header (rc-rpmman.c:1882) ==21323==by 0x4C4C10D: rc_rpmman_query (rc-rpmman.c:2321) ==21323==by 0x4C4DEE6: rc_rpmman_transact (rc-rpmman.c:1333) ==21323==by 0x4033ED: ??? (in /opt/novell/zenworks/lib/zmd/transact) ==21323==by 0x4038E2: main (in /opt/novell/zenworks/lib/zmd/transact) ==21323== Address 0x507cf98 is 8 bytes inside a block of size 40 free'd ==21323==at 0x4A04D72: free (vg_replace_malloc.c:325) ==21323==by 0x3322618438: rfree (rpmmalloc.c:78) ==21323==by 0x332221DC83: miFreeHeader (rpmdb.c:1541) ==21323==by 0x332221E9AD: rpmdbNextIterator (rpmdb.c:2064) ==21323==by 0x4C4BC59: rc_rpmman_find_system_headers (rc-rpmman.c:713) - ==21323==by 0x4C4C0C6: rc_rpmman_query (rc-rpmman.c:2312) ==21323==by 0x4C4DEE6: rc_rpmman_transact (rc-rpmman.c:1333) ==21323==by 0x4033ED: ??? (in /opt/novell/zenworks/lib/zmd/transact) ==21323==by 0x4038E2: main (in /opt/novell/zenworks/lib/zmd/transact) The Header object returned from rpmdbNextIterator is refcounted data. You are (likely, I can't see the code) using the header object outside the scope of an iterator. Make sure that you do something like myheader = headerLink(h); if you want to use a header outside of the scope of an iterator. You walso need to release the reference somewhere (void) headerFree(myheader); or you WILL have a memory leak. Note that all data retrieved through headerGet() implicitly relies on the reference count of the underlying header: the pointers to header tag data are all within the header object. hth 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM Libraries Crash in our custom library
On Jun 11, 2012, at 2:55 AM, Rajasekhar wrote: Problem : Unable to install the kernel rpm when we are trying to install the rpm via our customized backend library . This case is observed when we have two kernels already installed and we are trying to install the third kernel Description : We have a backend library through which we are calling the rpm api's to install/upgrade the rpm's . When we are trying to install the kernel rpm's using our backend library we are getting the exceptions in the rpm library and our library is crashing . Up on running the gdb the following trace is obtained . #0 0x003a4f417052 in indexCmp (avp=0x7fffe020, bvp=0x3df16ee538) at header.c:186 #1 0x003a4a834260 in bsearch () from /lib64/libc.so.6 #2 0x003a4f417816 in findEntry (h=0x10315d0, tag=RPMTAG_EPOCH, type=RPM_NULL_TYPE) at header.c:708 Hmmm … RPM_NULL_TYPE has never been used in RPM afaik. Offhand I'd guess that this SHOULD have been RPM_INT32_TYPE (unchecked: just a wild guess, there may be other explanations …) #3 0x003a4f419be3 in intGetTdEntry (h=0x10315d0, td=0x7fffe130, flags=HEADERGET_DEFAULT) at header.c:1304 #4 0x003a4f4175bb in headerGet (h=0x10315d0, tag=RPMTAG_EPOCH, td=0x7fffe130, flags=HEADERGET_DEFAULT) at header.c:1341 #5 0x77ddbc04 in headerGetEntryWrapper () from /opt/novell/zenworks/lib/zmd/libredcarpet.so.0 #6 0x77ddcb42 in rc_rpmman_read_header () from /opt/novell/zenworks/lib/zmd/libredcarpet.so.0 #7 0x77ddf469 in ?? () from /opt/novell/zenworks/lib/zmd/libredcarpet.so.0 #8 0x77de1202 in ?? () from /opt/novell/zenworks/lib/zmd/libredcarpet.so.0 as we can observe in the trace the exception is coming while reading the rpm headers . As part of installation we will be reading headers of a rpm using the headerGet call from rpm library and when we are trying to read the header information(epoch tag) the application is getting crashed. We are setting the following flags during the rpm transaction 1)RPMPROB_FILTER_REPLACEPKG 2)RPMPROB_FILTER_REPLACEOLDFILES 3)RPMPROB_FILTER_REPLACENEWFILES 4)RPMPROB_FILTER_OLDPACKAGE As we have limited knowledge on the rpm internals any help would be appreciated . The backend library source is located at http://download.opensuse.org/repositories/systemsmanagement:/zlm:/backend3/RedHat_RHEL-6/src/ if some one wants to take a look at it . Let me know if you need any more details. Note that the proper place to ask this question is likely OpenSUSE because its their libredcarpet and extensive set of patches to RPM (and this is @rpm5.org which is a different code base than SuSE uses). Red Carpet has also traditionally tried to dlopen(3) RPM libraries for version portability: is that still the case? Meanwhile if you can supply: 1) the exact version of RPM in use. 2) valgrind output (see below) with -v -v output enabled I can probably tell you what is wrong (or at least narrow down the possibilities and describe what to do next …) The usual problem with header segfaults is a missing reference count on the header somewhere. That guess can be confirmed by making a headerLink() call somewhere to see if the segfault disappears (but you will then have a (usually easier to solve) memory leak problem using valgrind). This is the usual way I invoke valgrind: valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --track-origins=yes \ whatever_command_you_want_to_debug Please try to also get -v -v (as on the rpm CLI) enabled because that helps provide context for analyzing the valgrind errors. hth 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
