Bug 1415791 - crash: double-free with --ignore-lock
Summary: crash: double-free with --ignore-lock
Alias: None
Product: Copr
Classification: Community
Component: backend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: clime
QA Contact:
Depends On: 1355720
TreeView+ depends on / blocked
Reported: 2017-01-23 17:58 UTC by Pavel Raiskup
Modified: 2017-11-09 15:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1355720
Last Closed: 2017-11-09 15:00:19 UTC

Attachments (Terms of Use)
Stacktrace from createrepo_c (48.42 KB, text/plain)
2017-11-03 07:29 UTC, clime
no flags Details

Description Pavel Raiskup 2017-01-23 17:58:44 UTC
This bug is for tracking createrepo_c issue.  We expect createrepo_c will be
fixed soon but for the time being we have patched createrepo_c for Internal Copr

Adding Fedora copr maintainer to CC, because it looks like createrepo_c
is is not (yet) rebuilt for F25 in copr repo, while upstream plans to migrate
to F25 soon.

Thanks to Kamil Dudka for re-reporting this issue.

Comment 1 Pavel Raiskup 2017-01-23 18:00:24 UTC
Michale, is that still necessary to use --ignore-lock option?

Comment 2 Pavel Raiskup 2017-01-23 18:23:35 UTC
Note for myself:
I can see that removing package on frontend leads to several "delete"
asynchronous actions on backend.  Each of them might lead to re-createrepo,
and I bet at least there we might face some race-conditions.

Comment 3 Pavel Raiskup 2017-08-16 06:54:16 UTC
This has been fixed in createrepo_c epel7 and fedora26+:

Since internal copr runs on F26 now, there's no need to track this anymore.

There's still opened question whether the --ignore-lock is needed on copr
backend so I'm switching this against upstream component.

Comment 4 clime 2017-11-03 07:29:09 UTC
Created attachment 1347182 [details]
Stacktrace from createrepo_c

Comment 5 clime 2017-11-03 07:36:20 UTC
We still use f25 createrepo_c. 

Version     : 0.10.0
Release     : 6.pr64and66.fc25

That's why the error is still there.

       Expert (risky) option: Ignore an existing .repodata/. (Remove the existing .repodata/ and create an empty new one to serve as a lock for other createrepo intances. For  the  repo‐
       data  generation,  a different temporary dir with the name in format .repodata.time.microseconds.pid/ will be used). NOTE: Use this option on your own risk! If two createrepos run
       simultaneously, then the state of the generated metadata is not guaranted - it can be inconsistent and wrong.

I am not understanding the whole thing here but according to last sentence, I think the --ignore-lock should be removed.

Comment 7 Pavel Raiskup 2017-11-03 08:08:33 UTC
(In reply to clime from comment #5)
> I am not understanding the whole thing here but according to last sentence,
> I think the --ignore-lock should be removed.

Absolutely, thank you.  If there's any issue with concurrency, and the locks
(huge delays), copr should make sure the concurrency doesn't happen (by e.g.
converting createrepo command into proper task -- maintained by frontend, and
executed by backend).

Comment 8 clime 2017-11-09 15:00:19 UTC
New COPR stack has been deployed.

Note You need to log in before you can comment on or make changes to this bug.