Difficult to reproduce problems while running tests

General
21

Aww, you got me an intractable problem to solve! But my birthday isn’t until the end of the month!

Reproduces for me too, running Arch under Docker under WSL2 on Windows 11. (@swi, thank you SO MUCH for the detailed repro! You may want to add diffutils to your package list, though, to avoid the not-found error from mkversion.sh - important, because the not-found causes unnecessary and distracting recompiles.)

Additionally,

touch PGO-data/pgo-run.stamp && ninja core

continues to reproduce the bug, but the following clears it:

rm -rf PGO-data && ninja core

meaning that the only difference between a working build and a buggy one (for me, at least) is the PGO profile data. In fact, I’ve got a PGO-data.buggy and PGO-data.working in this directory, and swapping between which one I’m using for the final compile does exactly what you’d expect. Continuing to dig, but here’s a question for you, @jan - what do you think might be different about the first time a PGO benchmark is run in a given directory that wouldn’t apply to any subsequent runs? Does swipl do any first-time optimizations the first time it runs that it would cache for subsequent runs?

22

Seems you’ve made more progress than I did :slight_smile:

Not that I’m aware of. There may be autoloading, but that should also happen on subsequent runs. make/0 isn’t used, so library indexes are not updated. Running a program can update outdated .qlf files. These simple benchmarks do not use any of these though and .qlf files should not be outdated.

Could it be that the presence of the old PGO data changes things?

23

Seems unlikely, since I removed the PGO-data directory before running the working build? That said, there are still artifacts from the previous build lying about that could alter things.