Bug 14182 - vulkan-samples reproducible failure
Summary: vulkan-samples reproducible failure
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: graphics (show other bugs)
Version: 3.4
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 3.3 M3
Assignee: Joshua Watt
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2021-01-11 11:49 UTC by Ross Burton
Modified: 2021-03-18 15:00 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Burton 2021-01-11 11:49:20 UTC
vulkan-samples-staticdev isn't reproducible:

https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210109-uud35nir/packages/
Comment 1 Richard Purdie 2021-01-13 23:47:06 UTC
Patch in testing and on mailing list
Comment 2 Randy MacLeod 2021-01-14 15:43:27 UTC
Richard's patch failed on the YP auto-builder. It seems that the debug data in the vulkan binary differs and depends on the path (Debug LOC section ?)
Comment 3 Richard Purdie 2021-01-19 18:04:18 UTC
I looked into this issue and whilst we fixed the first problem, there was in fact a second issue where some builds has differing libMachineIndependent.a files. This in turn was caused by differing ParseHelper.cpp.o files.

The difference was only in the .debug_loc section, there were no other differences in the binary. In general it was only a couple of loc entries that were different. I also confirmed that an annotated disassemble of ParseHelper.cpp.o was the same for both binaries.

After much debugging, I found that on a build which broke on the autobuilder, rebuilding the cmake_pch.hxx.gch file (the precompiled headers) then rebuilding ParseHelper.cpp.o resulted in the correct identical binary being generated. The discrepancy therefore seems to be in the precompiled headers.

I tried building the PCH at the start of a build and at the end of the build and also reproducing the exact order of build commands from log.do_compile from the broken build and couldn't reproduce the broken PCH file.

In the end I've turned of PCH in cmake for the recipe.
Comment 5 Joshua Watt 2021-03-18 15:00:35 UTC
Fixed on master