Bug 13656

Summary: rm_work race condition
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Jonathan Richardson <jon.richardson>
Component: oe-core otherAssignee: Ross Burton <ross.burton>
Status: RESOLVED NOTABUG QA Contact:
Severity: normal    
Priority: Undecided CC: scott.branden
Version: 3.0   
Target Milestone: ---   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
gperf-native build ouput none

Description Jonathan Richardson 2019-11-25 23:10:11 UTC
Created attachment 4590 [details]
gperf-native build ouput

I'm noticing a lot of random build failures (do_compile) on x86 native recipes. It appears there is a race condition in rm_work. I disabled a global inherit rm_work and the problem seems to go away. I attached the output of tmp/work/x86_64-linux/gperf-native. I can't figure out the logs. It looks like it was compiled multiple times. There is a do_compile.52119 at 1:48pm that succeeded. The log.do_rm_work is also at 1.48pm. But then do_compile runs again at 1:57 and there is no source code because it has been deleted. I'm using multiconfig. Not sure if that's what is causing it. I also noticed this on dwarfsrcfiles-native and many others.
Comment 1 Jonathan Richardson 2019-11-25 23:16:35 UTC
And I deleted my yocto-cache and build/tmp cache. So the logs weren't created from a previous build. Thanks.
Comment 2 Ross Burton 2019-11-26 11:41:08 UTC
If you're using multiconfig did you remember to set different TMPDIRs, as otherwise they'll be stamping on each other just like this.
Comment 3 Jonathan Richardson 2019-11-26 18:36:18 UTC
I didn't and I was hoping I didn't have to. The docs seemed to indicate it was optional so I tried without. The only reason is because we have a lot of build scripts and infrastructure depending on 'tmp'. I can try without. Apart from rm_work are there any other tasks that would get confused by not having different tmp dirs?
Comment 4 Jonathan Richardson 2019-11-26 18:47:26 UTC
Can yocto be made to know that the x86 native component required for one multiconfig is valid for another if they are the same? It would save having to re-compile it.
Comment 5 Ross Burton 2019-11-26 21:09:58 UTC
That's a known bug in the first release of multiconfig, since fixed in master.

If you don't put multiconfig builds in seperate TMPDIRs then breakage is your own problem.

It's easy to not hardcode tmp, worst case 'bitbake -e |grep TMPDIR=' to extract the current one.