New crash possibly related to generics & ObjC object instantiation in Swift 2.2 betas?

Using Swift
1

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.

2

Thanks for reporting the problem. We'll need a project that reproduces the crash to investigate—Have you filed a bug report?

-Joe

···

On Feb 10, 2016, at 9:54 AM, Evan Maloney via swift-users <swift-users@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

3

Hi Joe,

I haven't yet filed a radar but will do so when I get a chance & will attach our source project with test login credentials & steps to reproduce.

Thanks,
E.

···

On Feb 10, 2016, at 1:45 PM, Joe Groff <jgroff@apple.com> wrote:

Thanks for reporting the problem. We'll need a project that reproduces the crash to investigate—Have you filed a bug report?

-Joe

On Feb 10, 2016, at 9:54 AM, Evan Maloney via swift-users <swift-users@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

4

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

5

Joe,

I've filed rdar://problem/24592548 <rdar://problem/24592548>.

The ticket includes the source code, the Xcode project, the steps to reproduce & the login credentials needed to get to the crash site.

I've also included my phone number in case anyone needs help walking through those steps.

Thanks,
E.

···

On Feb 10, 2016, at 1:45 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

Thanks for reporting the problem. We'll need a project that reproduces the crash to investigate—Have you filed a bug report?

-Joe

On Feb 10, 2016, at 9:54 AM, Evan Maloney via swift-users <swift-users@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

6

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@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@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

7

Thanks, we'll take a look!

-Joe

···

On Feb 10, 2016, at 12:08 PM, Evan Maloney <emaloney@gilt.com> wrote:

Joe,

I've filed rdar://problem/24592548 <rdar://problem/24592548>.

The ticket includes the source code, the Xcode project, the steps to reproduce & the login credentials needed to get to the crash site.

I've also included my phone number in case anyone needs help walking through those steps.

8

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@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@apple.com <mailto:spestov@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@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

9

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@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@gilt.com <mailto:emaloney@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@apple.com <mailto:spestov@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@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

10

The fix should also be in the new Swift 2.2 snapshots Mish just posted, if you want to give that a try.

-Joe

···

On Feb 25, 2016, at 12:23 PM, Slava Pestov <spestov@apple.com> wrote:

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@gilt.com <mailto:emaloney@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@gilt.com <mailto:emaloney@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@apple.com <mailto:spestov@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@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

11

Great! I'll let you know when I give the next beta a try.

Thanks for the update,
Evan

···

On Feb 25, 2016, at 3:23 PM, Slava Pestov <spestov@apple.com> wrote:

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@gilt.com <mailto:emaloney@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@gilt.com <mailto:emaloney@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@apple.com <mailto:spestov@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@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

12

The fix should also be in the new Swift 2.2 snapshots Mish just posted, if you want to give that a try.

-Joe

Hi Joe,

Thanks a lot for the tip. I tried it using the Swift 2.2 snapshots from Feb. 24 in Xcode 7.3 beta 4 and can confirm that we are no longer able to trigger the crash using that version of the toolchain.

All the best,
Evan

···

On Feb 25, 2016, at 4:19 PM, Joe Groff <jgroff@apple.com> wrote:

On Feb 25, 2016, at 12:23 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:

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@gilt.com <mailto:emaloney@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.

13

Slava,

I am happy to report that the code in question no longer crashes as of the Xcode 7.3 beta 5 release!

Thanks a lot for shepherding this bugfix through the process.

All the best,
Evan

···

On Feb 29, 2016, at 4:25 PM, Evan Maloney <emaloney@gilt.com> wrote:

Great! I'll let you know when I give the next beta a try.

Thanks for the update,
Evan

On Feb 25, 2016, at 3:23 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:

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@gilt.com <mailto:emaloney@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@gilt.com <mailto:emaloney@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@apple.com <mailto:spestov@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@swift.org <mailto:swift-users@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@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users