<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Evan,<div class=""><br class=""></div><div class="">Sorry for the inconvenience!</div><div class=""><br class=""></div><div class="">The problem appears when accessing stored properties of a generic subclass of an @objc class that itself has no generically-sized members.</div><div class=""><br class=""></div><div class="">In your case, the HorizontalScrollViewController has two generic parameters DataModel and ViewModel, and inherits from UIViewController, but it doesn’t have any members which are value types written in terms of DataModel or ViewModel.</div><div class=""><br class=""></div><div class="">As a workaround, you can add a dummy stored property whose size depends on a generic parameter — the simplest would be an Optional initialized to nil:</div><div class=""><br class=""></div><div class=""> let _workaround: ViewModel? = nil</div><div class=""><br class=""></div><div class="">I tried this with the app from the radar and it appears to make it past the point where it previously crashed.</div><div class=""><br class=""></div><div class="">I’ll hopefully have a fix checked in tonight. The underlying issue is that a combination of two features goes bad:</div><div class=""><br class=""></div><div class="">- a generic class can be instantiated multiple times, resulting in multiple classes getting registered with the @objc runtime</div><div class="">- the Objective-C runtime ‘slides’ instance variable offsets to handle resilient changes to the size of a base class</div><div class="">- Swift’s runtime (incorrectly) skips some logic to instead ‘slide’ per-concrete type field offsets if the class does not contain any generally-sized members</div><div class=""><br class=""></div><div class="">Unfortunately, the generic_objc_subclass tests exercised instantiating a generic class multiple times, and the fixed-size case, but not both, so the regression came about when I refactored some code as part of implementing resilience (we can now have dynamically-sized members in non-generic classes, too, so a bunch of stuff in the runtime got moved around).</div><div class=""><br class=""></div><div class="">Slava</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I should have a fix ready shortly, but as a workaround, you might want to try <br class=""><div><blockquote type="cite" class=""><div class="">On Feb 10, 2016, at 9:54 AM, Evan Maloney via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div 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></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></blockquote></div><br class=""></div></body></html>