Bug 1415791

Summary: crash: double-free with --ignore-lock
Product: [Community] Copr Reporter: Pavel Raiskup <praiskup>
Component: backendAssignee: clime
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: clime, praiskup, tmlcoch
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1355720 Environment:
Last Closed: 2017-11-09 15:00:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1355720    
Bug Blocks:    
Attachments:
Description Flags
Stacktrace from createrepo_c none

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
purposes.

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+:
 https://src.fedoraproject.org/rpms/createrepo_c/c/6a445f4aa70d5b34820425f6502335efff3c3ff0?branch=master
https://src.fedoraproject.org/rpms/createrepo_c/c/886dc79f77b09443d8973055cdee473acc85a6cb?branch=epel7

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.

   --ignore-lock
       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 6 clime 2017-11-03 07:45:21 UTC 
Fixed by https://pagure.io/copr/copr/c/995042811bd4e5042d256e2ccde03a305e14713f?branch=master
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.