[SR-1055] Crash in libobjc when class's first stored property's type is not Objective-C compatible

[ChristopherRogers]

Previous ID	SR-1055
Radar	rdar://problem/25314388
Original Reporter	@ChristopherRogers
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

Swift 2.2 (Xcode 7.3)

Additional Detail from JIRA

Votes	1
Component/s	Compiler
Labels	Bug, Runtime
Assignee	@jckarter
Priority	Medium

md5: 0fc2f2b0678bcd1bad6330da7ad150ed

is duplicated by:

• SR-1210 Crash in libobjc when class's first stored property's type is not Objective-C compatible
• SR-1989 Crash at runtime when a class contains a struct having no property

Issue Description:

For example, attempting to use a class with just one stored property of an enum type that can't be represented in Objective-C will crash. It crashes in realizeClass when doing ivar offset stuff I believe (after turning on the debug logging for this).

Partial stack trace:

#0 0x0000000180d388e4 in realizeClass(objc_class*) ()
#1 0x0000000180d365ac in _class_getNonMetaClass ()
#2 0x0000000180d3b8b4 in lookUpImpOrForward ()
#3 0x0000000180d45d78 in _objc_msgSend_uncached_impcache ()
#4 0x00000001000cd958 in type metadata accessor for BadClass ()

[belkadan]

I think we're going to need a full project to make sure we're seeing the same issue. Thanks for reporting!

[belkadan]

Possibly the same as an internally-reported case, rdar://problem/25351783.

[ChristopherRogers]

I also had filed a radar a couple days ago, but I hadn't figured out anything in particular in Swift that was causing the problem at the time: rdar://problem/25330746

[ChristopherRogers]

I attached a sample project. It should crash from just running it (both device & simulator confirmed to crash).

[swift-ci]

Comment by Yasuhiro Inami (JIRA)

Same repro can be found in https://github.com/fmtonakai/SwiftPropertyCrash7_3

[gparker42]

Looks like a Swift compiler bug. It's emitting ObjC ivar offset variables into `_TEXT,_const`. libobjc crashes when it tries to update them.

[jckarter]

I think we want to emit the offsets as constants for a pure Swift root class, since our compiler also emits code that assumes the layout of the class. The ObjC runtime shouldn't need to slide pure Swift root classes, since the only base class from ObjC's perspective is the SwiftObject class that contains the Swift heap object header. The problem here is that, when we see a field with an empty type, we give it offset 0, which the ObjC runtime dutifully does try to slide.

[jckarter]

We accidentally set the instanceStart in the ObjC rodata for the class to 0 if the first field in the class had an empty type. Oops. Trying a fix in #1914 In the meantime, you can work around the problem by putting a non-empty field before your one-case enum field.

[jckarter]

Fixed in 2.2: ba1034b
and master: 822a6ab

[swift-ci]

Comment by James Campbell (JIRA)

I have encountered this bug with classes who don't just have one property. In my case the first property was an enum type and the following lazy properties and held a class.

Moving the lazy properties which held a class to be first instead of the enum property fixed the crash.

I was using Xcode 7.3 (Golden) and this was Swift 2.2.

[ChristopherRogers]

Yes, what actually triggers the bug is having a stored property with no actual storage (an enum with no cases) as the first property.

[swift-ci]

Comment by James Campbell (JIRA)

In my case my enum actually had one case and the crash still occurred, it occurred as part of XCTest looking up subclasses in the runtime for testing.

[jckarter]

An enum with only one case still doesn't need any storage, since there's only one valid state for the type.

[swift-ci]

Comment by James Campbell (JIRA)

@jckarter do you know when this will be available in Xcode ?

[jckarter]

I don't know what Xcode's release schedule is, sorry. I'll let you know when there's a release with a fix, though.