object.Exception@../src/asgen/contentsstore.d(67): mdb_txn_begin[22]: Invalid argument #85
Assignees
Labels
Comments
|
Very odd. This was on en empty workspace with no preexisting caches? Which exact version of lmdb are you using? (asgen will tell you the version when started in verbose mode at the beginning of the log) |
Also it seems to only happen on my setup when it starts processing the second architecture of the suite (e.g. |
|
That's likely because the cache is only full after parsing the second architecture, triggering this bug. You are not running multiple instances of asgen in parallel, right? (that wouldn't be supported). You could change like 201 in As said, transaction creation failure is a very odd failure mode :-/ |
|
Didn't help :( There are a bunch of |
|
Really very strange - did anything change to trigger this? |
|
You can try yourself, I'm using this config: {
"ProjectName": "postmarketOS",
"ArchiveRoot": "http://mirror.postmarketos.org/postmarketos/",
"Backend": "alpinelinux",
"Features":
{
"validateMetainfo": false,
"createScreenshotsStore": false,
"noDownloads": false
},
"Suites":
{
"v20.05":
{
"sections": ["postmarketos"],
"architectures": ["aarch64", "x86_64"]
}
}
}with the command |
|
I just hit this when trying to generate the Arch Linux metadata. I ran the generator on Aug 28th successfully for the last time, since then the only relevant change that I notice is an ldc update - but I can also reproduce the issue with the previous ldc version. For me it happens when moving from one section (repo) to the next one. Indexing a single repo works fine. |
|
Can you reproduce this every time as well? This is such a weird error, I really need to find a way to reproduce this (in the worst case by installing a VM/container/chroot with Arch, but for that I need to find the time). |
|
Yes, this is 100% reproducible. The weird thing is, I can still reproduce it after downgrading all packges to the point in time when I last ran the generator successfully. I'm not aware of any changes in the repos database format since then. Here is a minimal test case. |
|
@antonio-rojas Thank you for that great testcase! This was run on the current Git master version of |
|
Silly question, but: Where did you get LMDB 0.9.26 from? |
That mirror seems to no longer be synced. The official repo is https://git.openldap.org/openldap/openldap/tree/mdb.master (latest version is 0.9.27) |
|
With appstream{,-generator} from git master I get the same result on the same machines. In the meantime, I got a new laptop, and in this one it simply hangs |
|
This backtrace looks a bit like it is hanging in a GC collection cycle... Otherwise I can't explain why a GC allocation would be blocking in a mutex'ed version of the code (the trace misses debug symbols though, so maybe that causes it...) |
|
Okay, now I can reproduce the issue with your testcase 100% of the time. |
|
@antonio-rojas Could you test this patch? Works fine for me (and this behavior of LMDB was really strange... But fortunately not difficult to work around). |
|
Yes, this fixes both the crashes and the hang on my new laptop |
ximion
added a commit
that referenced
this issue
Jan 24, 2021
With the only-one-simultaneous-DB-env-open-per-thread behavior change, using the NOTLS option no longer appears to be necessary. CC: #85
|
Nice! Thank you a lot for your help, without your minimal testcase I would not have been able to find this issue! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm getting the following exception running appstream-generator with the Alpine backend:
Any idea what happens there? My workdir was clean before running appstream-generator
The text was updated successfully, but these errors were encountered: