<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello,<div class=""><br class=""></div><div class="">I've spent many hours banging my head against this one, and so far have come up empty. I'm wondering if anyone else is seeing the same issue.</div><div class=""><br class=""></div><div class="">We've been experiencing a perplexing new crash in the Swift 2.2 betas shipped with Xcode 7.3 beta 3 and below. I should point out that the code works fine in Swift 2.1 & 2.1.1 and we have a shipping app with many downloads and zero crashes of this kind occurring.</div><div class=""><br class=""></div><div class="">We've got a UIViewController subclass implemented in Swift that uses two generics: a DataModel and a ViewModel. The view controller contains a collection view whose cells also take a generic DataModel. At the implementation level, both of these generics are supplied as Swift structs.</div><div class=""><br class=""></div><div class="">At first, we were experiencing weird crashes during cell reuse within this view controller's collection view, so we turned on all the Diagnostic > Memory Management checkboxes for the build scheme. Once we did this, the crash shifted earlier in the program execution. So we knew it couldn't be bad cell reuse, since now the crashing was occurring before any cells were even instantiated.</div><div class=""><br class=""></div><div class="">When attempting to init() this UIViewController, we now see an EXC_BAD_ACCESS (code=1) within the init(). If we start commenting out various member variables, the crash shifts around. Sometimes the crash occurs on a simple var declaration. It's definitely not due to unwrapping a nil optional, since the crash occurs even when declaring a simple Int. For example, we added a single line as a test and the app crashes on this:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; line-height: normal; font-family: 'Input Mono';" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">public</span> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span> myInt = <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span>(<span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">3</span>)</div></div><div class=""><br class=""></div><div class="">Based on this behavior, the crash seems to be related to the allocation of the memory of the UIViewController itself.</div><div class=""><br class=""></div><div class=""><div class="">We tried running Instruments with the Zombie instrument. However, in the Xcode 7.3 betas, I am unable to get Instruments to successfully run *any* Swift application for longer than 2 seconds before it silently dies. It always stops with no message or any other indication that the app crashed.</div></div><div class=""><br class=""></div><div class="">A couple of us have developed a hunch it's related to generics somehow, since the only place we see the problem is the one place we're using generics at the UIViewController & UICollectionViewCell level.</div><div class=""><br class=""></div><div class="">Unfortunately, the place this occurs in our app is deep inside the user experience, and requires a valid login and an established account to access. I've tried to extract a test case, but have not yet been able to create a stand-alone project that reproduces the problem.</div><div class=""><br class=""></div><div class="">My concern is that even if we were to provide full source code to our app, it would be triaged down to the bottom since we don't have a decent test case.</div><div class=""><br class=""></div><div class="">Has anyone else seen anything like this, where perfectly fine Swift 2.1/2.1.1 code now crashes inexplicably under Swift 2.2?</div><div class=""><br class=""></div><div class="">I'm hoping we can find a way to supply a decent test case so this can get fixed before Swift 2.2 goes out the door.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">E.</div></body></html>