Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-4998] DropLastAnySeqCRangeIter benchmark crashes with Illegal instruction: 4 in debug build #47575

Open
palimondo mannequin opened this issue May 24, 2017 · 7 comments
Labels
benchmarks bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software run-time crash Bug → crash: Swift code crashed during execution standard library Area: Standard library umbrella

Comments

@palimondo
Copy link
Mannequin

palimondo mannequin commented May 24, 2017

Previous ID SR-4998
Radar rdar://problem/32402761
Original Reporter @palimondo
Type Bug
Environment

Swift version 4.0-dev (LLVM 8230c19f81, Clang 8d35d7d54c, Swift 45e5116)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA
Votes 0
Component/s Compiler, Standard Library
Labels Bug, Benchmark, RunTimeCrash
Assignee None
Priority Medium

md5: e7c58e560731e32e4e11200423303187

Issue Description:

The benchmark DropLastAnySeqCRangeIter crashes with

fatal error: file /Users/mondo/Developer/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/stdlib/public/core/8/Arrays.swift, line 3742
Illegal instruction: 4

when compiled in debug mode. This happens for example when running the benchmarks with build-script -B.

This issue is not reproducible when running benchmarks manually after -R build or build-script -R --debug-swift. (Running benchmarks manually, because SR-4357 is still an issue...)

@palimondo
Copy link
Mannequin Author

palimondo mannequin commented May 24, 2017

Same crash happens with DropLastAnySeqCRangeIterLazy, SuffixAnySeqCRangeIter and SuffixAnySeqCRangeIterLazy.

@belkadan
Copy link
Contributor

I suspect this is a real bug in the stdlib, not the compiler.

@swift-ci create

@palimondo
Copy link
Mannequin Author

palimondo mannequin commented May 25, 2017

I'm not so sure... if it were stdlib, it should be reproducible in build-script -R --debug-swift build, right? But it isn't reproducible there. From that it seem to be even further down the stack... LLVM?

@belkadan
Copy link
Contributor

Not sure why you would conclude that. A release build disables some checks, and can optimize over things that are technically not allowed.

@belkadan
Copy link
Contributor

Ah, in particular, --debug-swift does not imply --debug-swift-stdlib. That's probably the missing piece here.

@palimondo
Copy link
Mannequin Author

palimondo mannequin commented May 25, 2017

Aha! OK. I wasn't aware of --debug-swift-stdlib's existence and conflated those two in my head.

BTW, wouldn't it make sense to have one automated build run also in debug mode to catch stuff like this? I have accidentally stumbled upon this only because SR-4357 is still a thing...

@belkadan
Copy link
Contributor

We do have bots that build in debug mode, but they don't run the benchmarks because that won't generate any meaningful numbers. (Ideally the benchmarks wouldn't find any actual bugs not covered by the regular regression tests. Clearly that isn't where we are, though.)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added the crash Bug: A crash, i.e., an abnormal termination of software label Dec 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
benchmarks bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself crash Bug: A crash, i.e., an abnormal termination of software run-time crash Bug → crash: Swift code crashed during execution standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

2 participants