Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ChristopherRogers opened this issue Mar 24, 2016 · 16 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself runtime The Swift Runtime

Comments

@ChristopherRogers
Copy link
Contributor

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
Copy link
Contributor

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

@belkadan
Copy link
Contributor

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

@ChristopherRogers
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@swift-ci
Copy link
Collaborator

Comment by Yasuhiro Inami (JIRA)

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

@gparker42
Copy link
Mannequin

gparker42 mannequin commented Mar 26, 2016

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

Fixed in 2.2: ba1034b
and master: 822a6ab

@swift-ci
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Member

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

@swift-ci
Copy link
Collaborator

Comment by James Campbell (JIRA)

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

@jckarter
Copy link
Member

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.

@jckarter
Copy link
Member

In the meantime, you might verify with the new 2.2 snapshots that were released: https://swift.org/download/#snapshots

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself runtime The Swift Runtime
Projects
None yet
Development

No branches or pull requests

4 participants