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
Comments
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, |
Comment by Carmelo Gallo (JIRA) Seems related to SR-4478 as well. |
Comment by Carmelo Gallo (JIRA) Still not fixed in Xcode 8.3.1 |
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 |
Comment by Martin Škrovina (JIRA) I am also experiencing similar issue. I have a struct that is large and nested. The same code didn't crash with Xcode 8.2.1.
The `SomeLargeNestedStructType` has 52 variables and nested structs of depth ~7 (including system structs s.a. Array, Optional). |
Comment by Carmelo Gallo (JIRA) Still not fixed in Xcode 8.3.2 |
Comment by Martin Jakubec (JIRA) How does this look like guys? We can't use latest xcode until this is fixed. |
Comment by Carmelo Gallo (JIRA) Hi @slavapestov, any update about this issue? |
@swift-ci create |
Comment by Carmelo Gallo (JIRA) hi @slavapestov, any news on this? We really cannot keep working in this way. Carmelo |
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. |
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. |
carmelo.gallo (JIRA User) I have a workaround – in your build settings, add these two extra Swift compiler flags: -Xllvm -fast-isel=0 |
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? |
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. |
Comment by Carmelo Gallo (JIRA) Nice, thanks! |
Comment by Carmelo Gallo (JIRA) Hi @slavapestov, since we add those flags, the source editor keep crashing. |
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? |
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! |
Comment by José Manuel Sánchez (JIRA) It seems I have the same bug, but I'm seeing some differences here:
|
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). |
Hi everyone, this bug should be fixed in Xcode 9 beta 3. |
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. |
Attachment: Download
Environment
Xcode 8.3 (8E162)
Swift 3.1
Additional Detail from JIRA
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
The text was updated successfully, but these errors were encountered: