Crash on ios12.1 simulator

[shalinipk]

Short description of the issue:

Hello, seeing crashes on iOS 12.1 simulator (XCode 12) in Binder related code. Works fine on ios 13/14 simulators, also on physical device (ios14) Using RxSwift 6.0.0-rc.2

Was on XCode 11.7/RxSwift 5.1.0 earlier - where app ran fine on iOS versions 10 and above.

Thank you for your help.

Expected outcome:

No crash

What actually happens:

Self contained code example that reproduces the issue:

//binder definition extension Reactive where Base: DashboardDeviceMapView { var myCoordinate: Binder<CLLocationCoordinate2D?> { return Binder(self.base) { controller, coordinate in controller.myCoordinate = coordinate <--crashes here } } }

viewModel.mapMyCoordinate.drive(map.rx.myCoordinate).disposed(by: disposeBag)

//mapMyCoordinate defined as below var mapMyCoordinate: Driver<CLLocationCoordinate2D?> { get }

Platform/Environment

• [ X] iOS

How easy is to reproduce? (chances of successful reproduce after running the self contained code)

• [ X] easy, 100% repro

Xcode version:

12.3 beta

Installation method:

• [X ] Carthage

I have multiple versions of Xcode installed: (so we can know if this is a potential cause of your issue)

• [ X] yes (which ones) XCode 12.3 beta & XCode 11.7

Level of RxSwift knowledge: (this is so we can understand your level of knowledge and formulate the response in an appropriate manner)

• [X ] I have a significant code base

[freak4pc]

Hey @shalinipk - there were actually no code changes to Binder if you look at the source file so I',m not sure where a new crash would come from. Can you make sure you're on the last 6.0.0 and try go gather a reproducible example?

Thanks

[shalinipk]

Thanks. Let me move to RxSwift 6.0.0 (I am on 6.0.0-rc.2), and try again

[shalinipk]

Sorry to say - upgrading to 6.0.0 didn't resolve the crash. :(

I then downgraded RxSwift to 5.1.0 (I was previously on XCode 11.7, RxSwift 5.1.0 - upgraded to RxSwift 6.0.0 as part of moving to XCode 12) Now the crash is no more. App runs fine on ios 11, 12, 13 & 14

I did have to make a bunch of changes for the code to compile while upgrading from RxSwift 5.1.0 to 6.0.0. However I didn't have to make any changes in the Binder related code. Is there anything else I am missing ? Thanks for your help.

[denizak]

I've also experienced the issue, it is also crash when build into iOS 12 device. It crash immediately when trying to access an IBOutlet property, the view itself is applying a binder. Did i miss something? thanks

[freak4pc]

@shalinipk @denizak Do you mind providing a small project I can reproduce this on? I'll download an iOS 12 Simulator to test on.

Thanks!

[freak4pc]

@denizak @shalinipk - still waiting for your response.

[DivineDominion]

When running my app's tests, I found heap corruption errors at assignment statements as well. Only for me, it happens outside of Rx code. These were regular assignments to regular Swift objects, but Observables and AnyObserver properties were involved down the line. Sometimes the heap corruption was reported during deinit. This is all a bit flaky, but the memory issues could be related.

Downgrading to 5.x resolved these.

When it didn't crash on assignments or deinit, I could trigger Producer's abstract method's rxFatalError. Not sure how that happened, though. E.g. here https://github.com/ReactiveX/RxSwift/blob/0efa6d1482ddaea12d63f4f17567daa4744c7420/RxSwift/Observables/Producer.swift#L35

It's a macOS app. Am on Catalina, using Carthage to build RxSwift. Have tried 6.1.0 and 6.0.0 with no luck. I've not been using any unsafe Drivers or similar.

@freak4pc Was there some grand memory management change commit I could try to revert to and see if my heap corruptions occur around these commits?

[freak4pc]

There really wasn't anything substantial changes between 5.x and 6.x aside for new features and method renamed. Is there any chance you can try getting a smaller repro to analyze ?

[freak4pc]

Having some project that reproduces would make it easy to even do a git bisect and find the offending change

[DivineDominion]

Dang. If you don't have any suspicion, I'll try to bisect with commit-based checkouts of RxSwift until it stops crashing. I have no clue why it crashes in the first place, so I cannot extract a reproducible piece.

For posterity, the address sanitizer reports this:

SUMMARY: AddressSanitizer: heap-buffer-overflow Indexing.swift:35 in Indexing.init(indexChanges:repositoryEvents:repositoryObserver:)
Shadow bytes around the buggy address:
  0x1c0400011b20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
  0x1c0400011b30: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa
  0x1c0400011b40: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa
  0x1c0400011b50: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa
  0x1c0400011b60: fa fa fd fa fa fa fd fd fa fa 00 00 fa fa 00 00
=>0x1c0400011b70: fa fa 00 00[fa]fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400011b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400011b90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400011ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400011bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0400011bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
2021-02-13 09:14:40.858906+0100 The Archive[51951:1525274] =================================================================
2021-02-13 09:14:40.858991+0100 The Archive[51951:1525274] ==51951==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200008dba0 at pc 0x0001002f81b0 bp 0x7ffeefbfb0f0 sp 0x7ffeefbfb0e8
2021-02-13 09:14:40.859056+0100 The Archive[51951:1525274] WRITE of size 8 at 0x60200008dba0 thread T0
2021-02-13 09:14:40.859151+0100 The Archive[51951:1525274]     #0 0x1002f81af in Indexing.init(indexChanges:repositoryEvents:repositoryObserver:) Indexing.swift:35
2021-02-13 09:14:40.859207+0100 The Archive[51951:1525274]     #1 0x1079c75de in NullIndexing.init(indexChanges:repositoryEvents:repositoryObserver:) <compiler-generated>
2021-02-13 09:14:40.859267+0100 The Archive[51951:1525274]     #2 0x1079c7199 in NullIndexing.__allocating_init(indexChanges:repositoryEvents:repositoryObserver:) NullObjects.swift
2021-02-13 09:14:40.859332+0100 The Archive[51951:1525274]     #3 0x1079c6c91 in NullIndexing.__allocating_init() NullObjects.swift:37
2021-02-13 09:14:40.859381+0100 The Archive[51951:1525274]     #4 0x10813652b in default argument 0 of createServiceComponents(indexing:archiveMovedMonitor:search:display:select:selectOrCreate:matchOrCreate:draftNote:deleteNotes:configureDrafting:sort:generateZettelID:finishBuffering:processFileInteraction:openFileWithExternalEditor:creatingFile:writingFile:writingSelection:renamingFile:removingFile:recreatingNotes:creatingSavedSearch:editingSavedSearch:reorderingSavedSearch:removingSavedSearch:inMemoryIndexWirings:) Factories.swift:27
2021-02-13 09:14:40.859450+0100 The Archive[51951:1525274]     #5 0x108186dad in ArchiveSetupTests.BootstrappingDouble.init() ArchiveSetupTests.swift:15
2021-02-13 09:14:40.859503+0100 The Archive[51951:1525274]     #6 0x108186921 in ArchiveSetupTests.BootstrappingDouble.__allocating_init() ArchiveSetupTests.swift
2021-02-13 09:14:40.859548+0100 The Archive[51951:1525274]     #7 0x108190b27 in ArchiveSetupTests.setUp() ArchiveSetupTests.swift:63
2021-02-13 09:14:40.859605+0100 The Archive[51951:1525274]     #8 0x108191fc4 in @objc ArchiveSetupTests.setUp() <compiler-generated>
2021-02-13 09:14:40.859641+0100 The Archive[51951:1525274]     #9 0x10401b38f in __70-[XCTestCase _shouldContinueAfterPerformingSetUpSequenceWithSelector:]_block_invoke_2+0x1f2 (XCTest:x86_64+0x3238f)
... 

createServiceComponents is a factory method with lots of default values for intertwined service dependencies. All of them are Null-Objects, i.e. overrides with no-ops and other Null-Object stubs as dependencies. So there are a lot of allocations, and some allocate Observable.never()/.empty() and AnyObserver with an empty block. The crash occurs for the first default parameter value of this factory, and the class in question has:

public class Indexing {
    public let indexChanges: Observable<[IndexChanged]>
    public let repositoryEvents: Observable<OriginatedRepositoryEvent>
    public let repositoryObserver: AnyObserver<OriginatedRepositoryEvent> 
    ...
}

I'll report back once I finish bisecting to figure out when this error occurred. I hope that the source of this crash is also the source of the assignment crashes I experienced sometimes.

[DivineDominion]

Ok found the commit: https://github.com/ReactiveX/RxSwift/commit/ec30f1cb6c586df214ea07f9f9b78dd6366e478d

I checked by fetching HEAD@master and 6.1, which crashed as well, and turning BUILD_LIBRARY_FOR_DISTRIBUTION off again.

Since I'm using Carthage, this fixed it:

// add to your carthage.sh, like the one in https://github.com/Carthage/Carthage/issues/3019
echo 'BUILD_LIBRARY_FOR_DISTRIBUTION = NO' >> $xcconfig

@denizak @shalinipk Could you try to disable this setting in your Podfiles or what have you?

---

Note: I'm building a macOS app target only.

[shalinipk]

@freak4pc @DivineDominion sorry i didn't get a chance to get back earlier - was buried in a product release. Will try this out next week and get back to you. Thank you so much!!

[denizak]

@DivineDominion It's only happened to me when i set Release scheme and test it using iOS 12 device. When I build it using Debug Scheme, it is working fine. It is still happened on RxSwift 6.1

[freak4pc]

Both the trace and the fix @DivineDominion found indicate this is most likely a bug related to binary stability in iOS 12 (an Apple bug). Unsure if we can do anything about this aside for the manual workaround you noted above.

If someone can help share a reproducible project, that would immensely help and will also allow opening a bug on Apple's bug reporter.