[swift-users] New crash possibly related to generics & ObjC object instantiation in Swift 2.2 betas?

[Slava Pestov]

Hi Evan,

The fix did not make it in time for beta 4 but it should be in the next seed.

Slava

> On Feb 25, 2016, at 10:07 AM, Evan Maloney <emaloney at gilt.com> wrote:
> 
> Hi Slava,
> 
> As promised, I tried to reproduce the bug below (filed as rdar://problem/24592548 <rdar://problem/24592548>) once the new Xcode beta came out.
> 
> Unfortunately, under Xcode 7.3 beta 4 (7D152p), we're still seeing the crash.
> 
> Let me know if there's more info I can provide.
> 
> Thanks,
> E.
> 
> 
>> On Feb 11, 2016, at 11:38 PM, Evan Maloney <emaloney at gilt.com <mailto:emaloney at gilt.com>> wrote:
>> 
>> Slava,
>> 
>> Thanks for the quick reply. I'm blown away at how accessible and responsive the Swift team has been on these mailing lists. Past experience has 
>> 
>> Anyway, we had 2 classes requiring the work-around, but once I plugged it in, the crashes went away. I'm no longer able to trigger a crash.
>> 
>> When the next Xcode release comes out, I'll be sure to try it again--sans work-around--and I'll let you know how it goes.
>> 
>> Thanks again!
>> Evan
>> 
>> 
>> 
>> 
>>> On Feb 11, 2016, at 9:30 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>>> 
>>> Hi Evan,
>>> 
>>> Sorry for the inconvenience!
>>> 
>>> The problem appears when accessing stored properties of a generic subclass of an @objc class that itself has no generically-sized members.
>>> 
>>> 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.
>>> 
>>> 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:
>>> 
>>>     let _workaround: ViewModel? = nil
>>> 
>>> I tried this with the app from the radar and it appears to make it past the point where it previously crashed.
>>> 
>>> I’ll hopefully have a fix checked in tonight. The underlying issue is that a combination of two features goes bad:
>>> 
>>> - a generic class can be instantiated multiple times, resulting in multiple classes getting registered with the @objc runtime
>>> - the Objective-C runtime ‘slides’ instance variable offsets to handle resilient changes to the size of a base 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
>>> 
>>> 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).
>>> 
>>> Slava
>>> 
>>> 
>>> I should have a fix ready shortly, but as a workaround, you might want to try 
>>>> On Feb 10, 2016, at 9:54 AM, Evan Maloney via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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:
>>>> 
>>>>     public var myInt = Int(3)
>>>> 
>>>> Based on this behavior, the crash seems to be related to the allocation of the memory of the UIViewController itself.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> Has anyone else seen anything like this, where perfectly fine Swift 2.1/2.1.1 code now crashes inexplicably under Swift 2.2?
>>>> 
>>>> 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.
>>>> 
>>>> Thanks,
>>>> E.
>>>> _______________________________________________
>>>> swift-users mailing list
>>>> swift-users at swift.org <mailto:swift-users at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160225/9a53b3a3/attachment.html>