Bug 12594 - large number of host-user-contaminated QA warnings with Fedora 27
Summary: large number of host-user-contaminated QA warnings with Fedora 27
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 2.5
Hardware: x86 Multiple
: High major
Target Milestone: 2.5 M4
Assignee: Jackie Huang
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2018-03-08 17:39 UTC by California Sullivan
Modified: 2018-04-04 03:08 UTC (History)
7 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
log (23.15 KB, text/plain)
2018-03-08 17:39 UTC, California Sullivan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description California Sullivan 2018-03-08 17:39:34 UTC
Created attachment 4230 [details]
log

I'm reliably seeing a large number of host-user-contaminated warnings with poky, mostly against glibc, coreutils, and ncurses, on Fedora 27.

Attached is the log of a fresh clone of poky followed by a core-image-minimal build, where I get a couple hundred lines of warnings.

This also occurs with the HEAD and yocto-2.4.1 tag of rocko, so its not recent.

I didn't see this immediately upon upgrade to Fedora 27. I think it started happening when I wiped out my sstate cache.

This could be related to bug 12434.
Comment 1 Randy MacLeod 2018-03-15 10:22:05 UTC
I was able to reproduce the problem on my Fedora 27 system as well.
Nothing jumped out of the logs so it's likely a pseudo regression.
Comment 2 Ross Burton 2018-03-15 13:15:04 UTC
Can you replicate with rocko branch so we can determine if its a F27 change, or the pseudo upgrade?

CCing Seebs.
Comment 3 Seebs 2018-03-15 13:22:21 UTC
Huh, interesting! Would like to see a small reproducer. The main place I'd be looking for things would be the general vicinity of the O_TMPFILE changes, but I didn't think that was heavily used. Unless it's related to the mk*temp() functions, but again, thought those were lightly used.
Comment 4 California Sullivan 2018-03-15 16:47:33 UTC
A quick reproducer for me:

bitbake gawk -c cleanall; bitbake gawk
Comment 5 Ross Burton 2018-03-16 03:06:44 UTC
-ccleanall is an antipattern, to force a rebuild use bitbake -C unpack gawk.
Comment 6 Randy MacLeod 2018-03-19 08:22:01 UTC
It happens on rocko HEAD and several other commits before that. Can't bisect because of a build failure. I'm guessing it's host-user-contaminated all the way down.
Comment 7 Ross Burton 2018-03-22 07:50:44 UTC
My hunch is that glibc 2.27 is using some functions which pseudo isn't intercepting?
Comment 8 Seebs 2018-03-22 08:07:41 UTC
That seems pretty likely. I don't have a Fedora 27 box handy, though.
Comment 9 Ross Burton 2018-03-23 09:28:33 UTC
| $ ltrace mv foo bar
| ...
| syscall(316, 0xffffff9c, 0x7fff1564a341, 0xffffff9c) = 0

Yeah, that would do it.

Any F27 machine with https://src.fedoraproject.org/rpms/coreutils/c/79fe59c7fc11afa211a15bfcf28f4ca76f42c645?branch=master will be hitting this.