[SR-9298] Crash with IOU and Existentials

[palimondo]

Previous ID	SR-9298
Radar	None
Original Reporter	@palimondo
Type	Bug
Status	Closed
Resolution	Invalid

Environment

swift master

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, RunTimeCrash
Assignee	@aschwaighofer
Priority	Medium

md5: becc24754abb11e0ec60755f3f8eca1c

Issue Description:

In the ExistentialPerformance.swift from Swift Benchmark Suite, I'm seeing a runtime crash when releasing IOU Existential. This issue does not occur when I've copied the code into minimal test-case. It appears to be somehow specific to SBS. The code to reproduce the issue is in PR #20666.

The scenario where the bug occurs is described in the comment. To reproduce, clone the PR and uncomment the body in `grabArray` function.

[belkadan]

cc @slavapestov, @mikeash, @eeckstein

[slavapestov]

IUO does not have a runtime representation so it should be possible to reproduce the issue with a plain Optional.

[palimondo]

@slavapestov As I said in the description, this issue wasn't reproducible outside of Swift Benchmarking Suite, even when I have copied the code unchanged. It's a stretch to say it should be reproducible with Optional… Can somebody have a look at this? (I'm hesitant to finish the PR with unresolved issues around benchmark setup overhead this bug is causing.)

[palimondo]

This bug is still reproducible by uncommenting the alternative grabArray in the PR #20666 which has been rebased on latest master.

[palimondo]

PR #20666 has been merged (the benchmarks were refactored, but remain skipped from the pre-commit performance testing), so it should now be possible for everybody to reproduce this bug on master by uncommenting the alternative versions of grabArray.

[palimondo]

cc aschwaighofer@apple.com (JIRA User), @eeckstein

[palimondo]

Ehm. I apologize, am an idiot… there is no bug here. This is crashing on a second sample, when the grabbed array is indeed set to nil, ergo the crash when dereferencing the Optional.

The proper way to get rid of the setup overhead in those benchmarks is to copy the fresh array on each iteration, which also fixes the different amount of work these tests were doing between first and subsequent iterations.