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-4432] EXC_BAD_ACCESS on devices if nested structs are used with Xcode 8.3 and Swift 3.1 #47009

Closed
swift-ci opened this issue Mar 30, 2017 · 24 comments
Assignees
Labels
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

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-4432
Radar rdar://problem/31874834
Original Reporter carmelo.gallo (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

Xcode 8.3 (8E162)
Swift 3.1

Additional Detail from JIRA
Votes 6
Component/s Compiler
Labels Bug, RunTimeCrash
Assignee @slavapestov
Priority Medium

md5: e41e28f5b44c5cf6d0979d5bf0377e5a

Issue Description:

Hey guys!

Like I wrote in the title, I got an EXC_BAD_ACCESS on device if nested structs are used with Xcode 8.3 and Swift 3.1. It was working properly with Xcode 8.2.1

I've attached an example project so you guys can test it.

My thought is that there is a problem with allocating memory for more than 4 level nested structs.
It's confirmed that the problem appears if the struct is larger than 4K in base of @slavapestov answer:
"It looks like if the struct is larger than 4K we sometimes emit an incorrect instruction sequence. r31 inside an add instruction is interpreted as the zero register and not as the stack pointer."

Looking forward to your replay, cheers!

Carmelo

@swift-ci
Copy link
Collaborator Author

Comment by Carmelo Gallo (JIRA)

Hi @belkadan, any update on this? It's quite important for us and would be nice to have it fixed asap. We need to use the new "-enable-bridging-pch" feature due to the project now is taking ~20 mins before the compiling is done. With that enabled it took ~4 mins 🙂

Please let me know something asap, thanks.

Cheers,
Carmelo

@swift-ci
Copy link
Collaborator Author

Comment by Carmelo Gallo (JIRA)

I just discovered that changing the Optimization Level in Build Settings to "Fast, Single-File Optimization [-O]" or "Fast, Whole Module Optimization [-O -whole-module-optimization]" the crash is gone. Look at the attached image.

Is that helpful?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 4, 2017

Comment by Carmelo Gallo (JIRA)

Seems related to SR-4478 as well.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 7, 2017

Comment by Carmelo Gallo (JIRA)

Still not fixed in Xcode 8.3.1

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 7, 2017

Comment by Cameron McOnie (JIRA)

I am experiencing a similar issue. EXC_BAD_ACCESS crash on assigning a nested struct.

This issue is only reproducible on Swift 3.1 and Xcode 8.3

@swift-ci
Copy link
Collaborator Author

Comment by Martin Škrovina (JIRA)

I am also experiencing similar issue. I have a struct that is large and nested.
I get EXC_BAD_ACCESS when assigning initialized struct or nil to a variable of the optional struct type.

The same code didn't crash with Xcode 8.2.1.
It crashes with Xcode 8.3 & 8.3.1 when run on device (iPad Air 2) and compiled without optimizations.
When run on simulator or compiled with optimizations, the code doesn't crash.

let nilStruct: SomeLargeNestedStructType? = nil
print(nilStruct == nil) // Causes EXC_BAD_ACCESS (code=1, address=....
let someStruct: SomeLargeNestedStructType? = SomeLargeNestedStructType()
print(someStruct == nil) // Causes EXC_BAD_ACCESS (code=1, address=....
let aStruct: SomeLargeNestedStructType = SomeLargeNestedStructType()
print(aStruct) // is OK...

The `SomeLargeNestedStructType` has 52 variables and nested structs of depth ~7 (including system structs s.a. Array, Optional).

@swift-ci
Copy link
Collaborator Author

Comment by Carmelo Gallo (JIRA)

Still not fixed in Xcode 8.3.2

@swift-ci
Copy link
Collaborator Author

Comment by Martin Jakubec (JIRA)

How does this look like guys? We can't use latest xcode until this is fixed.

@swift-ci
Copy link
Collaborator Author

Comment by Carmelo Gallo (JIRA)

Hi @slavapestov, any update about this issue?

@slavapestov
Copy link
Member

@swift-ci create

@swift-ci
Copy link
Collaborator Author

swift-ci commented May 8, 2017

Comment by Carmelo Gallo (JIRA)

hi @slavapestov, any news on this? We really cannot keep working in this way.

Carmelo

@swift-ci
Copy link
Collaborator Author

Comment by Luke Street (JIRA)

I have also ran into this issue. Changing optimization level to "Fast, Single-File Optimization [-O]" worked for me as well, but this obviously still needs a fix. One thing I noticed is it is not necessarily the number of nested structs that causes the issue. I can have the same level of nesting, but when I lessen the amount of data in each different structs the crash will sometimes go away. My thought is it might have trouble allocating space for structs that are within certain ranges of sizes.

@slavapestov
Copy link
Member

It looks like if the struct is larger than 4K we sometimes emit an incorrect instruction sequence. r31 inside an add instruction is interpreted as the zero register and not as the stack pointer.

@slavapestov
Copy link
Member

carmelo.gallo (JIRA User) I have a workaround – in your build settings, add these two extra Swift compiler flags: -Xllvm -fast-isel=0

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jun 9, 2017

Comment by Carmelo Gallo (JIRA)

Hi @slavapestov, thanks for the answer. Yes the workaround is working 😃 Thanks for the effort 😉

Just curious what those flags are doing. May you explain that? Also, in which version of Xcode/Swift will this bug be fixed?

@slavapestov
Copy link
Member

The fast instruction selector that is used for non-optimized builds produces an invalid ARM64 instruction sequence when stack allocating a large value type. This doesn't affect other architectures or the SelectionDAG instruction selector in optimized builds.

I'll update this bug when we make progress on the fix.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jun 9, 2017

Comment by Carmelo Gallo (JIRA)

Nice, thanks!

@swift-ci
Copy link
Collaborator Author

Comment by Carmelo Gallo (JIRA)

Hi @slavapestov, since we add those flags, the source editor keep crashing.

@swift-ci
Copy link
Collaborator Author

Comment by José Manuel Sánchez (JIRA)

I'm also hitting this bug, but the workaround is not working for me. Actually in some cases it wasn't crashing and adding the workaround made it crash. Any ideas how we can workaround this until it's fixed?

@swift-ci
Copy link
Collaborator Author

Comment by Vicente Crespo (JIRA)

+1 Please, this is critical and we are investing tons of hours trying to move around this bug that keeps popping up spontaneously.

I'm having the same exact situation as buscarini (JIRA User) is.

Pretty please, keep being awesome!

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jul 5, 2017

Comment by José Manuel Sánchez (JIRA)

It seems I have the same bug, but I'm seeing some differences here:

  • Whole Module Optimization doesn't solve it for us

  • "-Xllvm -fast-isel=0" doesn't solve it

  • It usually crashes when passing a big struct as the argument of a function

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jul 6, 2017

Comment by José Manuel Sánchez (JIRA)

Correction:

We had different configurations, and it seems that we weren't actually using optimization. It seems that enabling optimization does make this bug go away (even without whole module optimization).

@slavapestov
Copy link
Member

Hi everyone, this bug should be fixed in Xcode 9 beta 3.

@swift-ci
Copy link
Collaborator Author

Comment by Carmelo Gallo (JIRA)

😃😃😃 Thanks man! Even thought I expected to have it like an hot-fix for Xcode 8.3.4

Better than nothing at the end 🙂

I'll check and I'll keep you posted.

@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
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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
Projects
None yet
Development

No branches or pull requests

3 participants