[Rpm-maint] [rpm-software-management/rpm] 3 cleanup fixes (#359)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/359 -- Commit Summary -- * ndb glue: closeEnv() should always clear rdb->db_dbenv * rpmidxHandleObsolete(): Fix fd leak in error path * Fix leak with openDatabase() / rpmdbClose() * gitignore update -- File Changes -- M .gitignore (2) M lib/backend/ndb/glue.c (2) M lib/backend/ndb/rpmidx.c (6) M lib/rpmdb.c (17) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/359.patch https://github.com/rpm-software-management/rpm/pull/359.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/359 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix error message for rpmlock (#355), by removing dead code (#358)
(plus one bonus commit, hope that's ok) --- rpmlock_acquire() failed to set errno, when it failed to acquire a write-lock on a lock which was opened as read-only. errno was printed in the error message, so the error message was arbitrary. Typically the previous errno happened to be the right one, but if STDIN was not a TTY, then it was not. (Due to an intervening call to isatty()). A one-line fix to set errno appropriately would not fix #355. Because the appropriate errno for performing write operations on a read-only handle is EBADF. This is too generic to tell the user what the real problem is (i.e. that rpm was run without the necessary privilege to write to the lock file). This obstacle would disappear if we could avoid the automatic fallback from a read-write open() to a read-only open(). It turns out that rpmlock.h never exported a read-only lock feature, so this was never used. Remove the code for automatic fallback to read-only and read-only locks. This makes #355 go away. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/358 -- Commit Summary -- * Fix error message for rpmlock (#355), by removing dead code * rpmlock_new(): use xcalloc() -- File Changes -- M lib/rpmlock.c (60) M lib/rpmlock.h (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/358.patch https://github.com/rpm-software-management/rpm/pull/358.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/358 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpmidxGetInternal(): leak on realloc() failure (#357)
When realloc() fails the original allocation remains, and should be freed at
some point.
Can rpmidxGetInternal() be converted to xrealloc() ? I'm unsure because there
might be a deliberate reason, e.g. why we still have 130 references directly to
malloc() and not xmalloc().
```
@@ -927,16 +927,14 @@ static int rpmidxGetInternal(rpmidxdb idxdb, const
unsigned char *key, unsigned
}
if (keyoff != x)
continue;
if ((nhits & 15) == 0) {
if (!hits) {
- hits = malloc(16 * sizeof(unsigned int));
+ hits = xmalloc(16 * sizeof(unsigned int));
} else {
- hits = realloc(hits, (nhits + 16) * sizeof(unsigned int));
+ hits = xrealloc(hits, (nhits + 16) * sizeof(unsigned int));
}
- if (!hits)
- return RPMRC_FAIL;
}
data = le2ha(ent + 4);
ovldata = (data & 0x8000) ? le2ha(idxdb->slot_mapped +
idxdb->nslots * 8 + 4 * h) : 0;
hits[nhits++] = decodedata(idxdb, data, ovldata, );
hits[nhits++] = datidx;
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/357___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm without TTY gives wrong error message (#355)
In the meanwhile I manually merged this one with somewhat different commit message, the EROFS-specific test was dumb anyhow. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/355#issuecomment-343868388___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
