iOS 10: Sectioned ListMonitor crashing with EXC_BAD_ACCESS #85

@JohnEstropia commented on GitHub (Sep 23, 2016):

Your EXC_BAD_ACCESS indicates EXC_I386_GPFLT, and your simulator is iPhone 5s, which leads me to believe that there is a 32-bit-related problem somewhere. Maybe a property which your SectionBy("id") relies on? Maybe try

@NSManaged var id: NSNumber

instead of

@NSManaged var id: IntXX

@JohnEstropia commented on GitHub (Sep 23, 2016): Your EXC_BAD_ACCESS indicates `EXC_I386_GPFLT`, and your simulator is iPhone 5s, which leads me to believe that there is a 32-bit-related problem somewhere. Maybe a property which your `SectionBy("id")` relies on? Maybe try ``` swift @NSManaged var id: NSNumber ``` instead of ``` swift @NSManaged var id: IntXX ```

adam commented

@JohnEstropia commented on GitHub (Sep 23, 2016):

Oh oops, it turns out EXC_I386_GPFLT has nothing to do with floats, but General Protected Fault, which has more to do with accessing invalid memory (zombies)

@JohnEstropia commented on GitHub (Sep 23, 2016): Oh oops, it turns out EXC_I386_GPFLT has nothing to do with floats, but `General Protected Fault`, which has more to do with accessing invalid memory (zombies)

adam commented

@jamesbebbington commented on GitHub (Sep 23, 2016):

Yeah, my id property is already declared as an NSNumber.

N.B. I'm actually grouping by a related model, but I changed it to id as you see above, to see if that was causing the crash.

@jamesbebbington commented on GitHub (Sep 23, 2016): Yeah, my `id` property is already declared as an `NSNumber`. N.B. I'm actually grouping by a related model, but I changed it to `id` as you see above, to see if that was causing the crash.

adam commented

@JohnEstropia commented on GitHub (Sep 23, 2016):

Hmm... Can you put an Exception Breakpoint and see where the error was thrown from?

@JohnEstropia commented on GitHub (Sep 23, 2016): Hmm... Can you put an Exception Breakpoint and see where the error was thrown from?

adam commented

@jamesbebbington commented on GitHub (Sep 23, 2016):

No difference, I'm afraid:

@jamesbebbington commented on GitHub (Sep 23, 2016): No difference, I'm afraid: <img width="1084" alt="screen shot 2016-09-23 at 15 40 44" src="https://cloud.githubusercontent.com/assets/5934/18789812/3bb5ac2c-81a4-11e6-9d3d-3d3be1415002.png"> <img width="1084" alt="screen shot 2016-09-23 at 15 41 30" src="https://cloud.githubusercontent.com/assets/5934/18789813/3bd088d0-81a4-11e6-801b-f9961d2b4ea8.png">

adam commented

@JohnEstropia commented on GitHub (Sep 23, 2016):

One last thing I can think of, do all your relationships have inverse relationships?

If that's not it either then I have no leads right now... Can you isolate the crash in a smaller project? (maybe using CoreStore's demo app)

@JohnEstropia commented on GitHub (Sep 23, 2016): One last thing I can think of, do all your relationships have inverse relationships? If that's not it either then I have no leads right now... Can you isolate the crash in a smaller project? (maybe using CoreStore's demo app)

adam commented

@jamesbebbington commented on GitHub (Sep 23, 2016):

One last thing I can think of, do all your relationships have inverse relationships?

Yeah, just checked and can't see anything wrong with them.

If that's not it either then I have no leads right now... Can you isolate the crash in a smaller project? (maybe using CoreStore's demo app)

That was my original plan when filing this ticket - I've attempted to created a stand-alone minimal test case app that exhibits this crash but I haven't managed to replicate it unfortunately.

@jamesbebbington commented on GitHub (Sep 23, 2016): > One last thing I can think of, do all your relationships have inverse relationships? Yeah, just checked and can't see anything wrong with them. > If that's not it either then I have no leads right now... Can you isolate the crash in a smaller project? (maybe using CoreStore's demo app) That was my original plan when filing this ticket - I've attempted to created a stand-alone minimal test case app that exhibits this crash but I haven't managed to replicate it unfortunately.

adam commented

2025-12-29 15:24:03 +01:00

@laeroah commented on GitHub (Sep 23, 2016):

I have this issue too. Only happens on iOS10.

@laeroah commented on GitHub (Sep 23, 2016): I have this issue too. Only happens on iOS10.

adam commented

@laeroah commented on GitHub (Sep 23, 2016):

Crash log:

Crashed: NSManagedObjectContext 0x1701c9330: com.corestore.rootcontext
0  libobjc.A.dylib                0x18ce15704 objc_object::release() + 8
1  libobjc.A.dylib                0x18ce15fe0 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 704
2  CoreFoundation                 0x18e29ddb8 _CFAutoreleasePoolPop + 28
3  Foundation                     0x18edb3bf0 -[NSAutoreleasePool drain] + 148
4  CoreData                       0x19077c438 gutsOfBlockToNSPersistentStoreCoordinatorPerform + 192
5  CoreData                       0x19076b8ac -[NSPersistentStoreCoordinator performBlockAndWait:] + 196
6  CoreData                       0x190737b68 developerSubmittedBlockToNSManagedObjectContextPerform + 152
7  libdispatch.dylib              0x18d24d1c0 _dispatch_client_callout + 16
8  libdispatch.dylib              0x18d25a860 _dispatch_barrier_sync_f_invoke + 84
9  CoreData                       0x190737a78 -[NSManagedObjectContext performBlockAndWait:] + 308
10 CoreData                       0x190783db4 -[NSFetchedResultsController _recursivePerformBlockAndWait:withContext:] + 144
11 CoreData                       0x190737b68 developerSubmittedBlockToNSManagedObjectContextPerform + 152
12 CoreData                       0x190737a48 -[NSManagedObjectContext performBlockAndWait:] + 260
13 CoreData                       0x190783db4 -[NSFetchedResultsController _recursivePerformBlockAndWait:withContext:] + 144
14 CoreData                       0x1906a882c -[NSFetchedResultsController performFetch:] + 264
15 CoreStore                      0x1018a8ec8 CoreStoreFetchedResultsController.performFetchFromSpecifiedStores() throws -> () (CoreStoreFetchedResultsController.swift:98)

@laeroah commented on GitHub (Sep 23, 2016): Crash log: ``` Crashed: NSManagedObjectContext 0x1701c9330: com.corestore.rootcontext 0 libobjc.A.dylib 0x18ce15704 objc_object::release() + 8 1 libobjc.A.dylib 0x18ce15fe0 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 704 2 CoreFoundation 0x18e29ddb8 _CFAutoreleasePoolPop + 28 3 Foundation 0x18edb3bf0 -[NSAutoreleasePool drain] + 148 4 CoreData 0x19077c438 gutsOfBlockToNSPersistentStoreCoordinatorPerform + 192 5 CoreData 0x19076b8ac -[NSPersistentStoreCoordinator performBlockAndWait:] + 196 6 CoreData 0x190737b68 developerSubmittedBlockToNSManagedObjectContextPerform + 152 7 libdispatch.dylib 0x18d24d1c0 _dispatch_client_callout + 16 8 libdispatch.dylib 0x18d25a860 _dispatch_barrier_sync_f_invoke + 84 9 CoreData 0x190737a78 -[NSManagedObjectContext performBlockAndWait:] + 308 10 CoreData 0x190783db4 -[NSFetchedResultsController _recursivePerformBlockAndWait:withContext:] + 144 11 CoreData 0x190737b68 developerSubmittedBlockToNSManagedObjectContextPerform + 152 12 CoreData 0x190737a48 -[NSManagedObjectContext performBlockAndWait:] + 260 13 CoreData 0x190783db4 -[NSFetchedResultsController _recursivePerformBlockAndWait:withContext:] + 144 14 CoreData 0x1906a882c -[NSFetchedResultsController performFetch:] + 264 15 CoreStore 0x1018a8ec8 CoreStoreFetchedResultsController.performFetchFromSpecifiedStores() throws -> () (CoreStoreFetchedResultsController.swift:98) ```

adam commented

2025-12-29 15:24:03 +01:00

@jamesbebbington commented on GitHub (Sep 23, 2016):

Sorry to hear it's biting you too @laeroah.

I said:

I've attempted to created a stand-alone minimal test case app that exhibits this crash but I haven't managed to replicate it unfortunately.

Here's my attempt at creating a minimal test case. @laeroah perhaps you can replicate the crash on that app?

@jamesbebbington commented on GitHub (Sep 23, 2016): Sorry to hear it's biting you too @laeroah. I said: > I've attempted to created a stand-alone minimal test case app that exhibits this crash but I haven't managed to replicate it unfortunately. Here's my attempt at creating [a minimal test case](https://github.com/jamesbebbington/CoreStore-SectionedList-TestCase). @laeroah perhaps you can replicate the crash on that app?

adam commented

2025-12-29 15:24:03 +01:00

@laeroah commented on GitHub (Sep 23, 2016):

Ok, I think I can reproduce the issue:
In CountriesTableViewController change the monitorSectionedList part to:

    let countries: ListMonitor<Country> = CoreStore.monitorSectionedList(
        From(Country),
        SectionBy("continent.name"),
        OrderBy(.Ascending("continent.name")),
        Tweak { (fetchRequest) -> Void in
            fetchRequest.fetchBatchSize = 20
        }
    )

Crashes every time.

@laeroah commented on GitHub (Sep 23, 2016): Ok, I think I can reproduce the issue: In `CountriesTableViewController` change the monitorSectionedList part to: ``` let countries: ListMonitor<Country> = CoreStore.monitorSectionedList( From(Country), SectionBy("continent.name"), OrderBy(.Ascending("continent.name")), Tweak { (fetchRequest) -> Void in fetchRequest.fetchBatchSize = 20 } ) ``` Crashes every time.

adam commented

2025-12-29 15:24:04 +01:00

@JohnEstropia commented on GitHub (Sep 23, 2016):

Wow, awesome detective work guys, thanks :)

So the problem is with fetchBatchSize? If so this sounds like an iOS 10 bug :( I'll try to find a workaround (if i can also reproduce it)

@JohnEstropia commented on GitHub (Sep 23, 2016): Wow, awesome detective work guys, thanks :) So the problem is with fetchBatchSize? If so this sounds like an iOS 10 bug :( I'll try to find a workaround (if i can also reproduce it)

adam commented

2025-12-29 15:24:04 +01:00

@laeroah commented on GitHub (Sep 23, 2016):

thank you!
seems putting anything inside Tweak will crash. Not just fetchBatchSize. One property I really need to set is includesSubentities, so anyway to do that around without using Tweak clause?

@laeroah commented on GitHub (Sep 23, 2016): thank you! seems putting anything inside `Tweak` will crash. Not just fetchBatchSize. One property I really need to set is `includesSubentities`, so anyway to do that around without using Tweak clause?

adam commented

@JohnEstropia commented on GitHub (Sep 23, 2016):

Huh, It doesn't crash on my side with @jamesbebbington's repo and @laeroah's edit...

@JohnEstropia commented on GitHub (Sep 23, 2016): Huh, It doesn't crash on my side with @jamesbebbington's repo and @laeroah's edit...

adam commented

@jamesbebbington commented on GitHub (Sep 23, 2016):

Huh, It doesn't crash on my side with @jamesbebbington's repo and @laeroah's edit...

It does for me.

seems putting anything inside Tweak will crash.

And I'm not Tweaking in my example:

@jamesbebbington commented on GitHub (Sep 23, 2016): > Huh, It doesn't crash on my side with @jamesbebbington's repo and @laeroah's edit... It does for me. > seems putting anything inside `Tweak` will crash. And I'm not `Tweak`ing in my example: <img width="1088" alt="screen shot 2016-09-22 at 17 44 21" src="https://cloud.githubusercontent.com/assets/5934/18757573/5c127fa8-80ec-11e6-8007-631daf913a62.png">

adam commented

@JohnEstropia commented on GitHub (Sep 23, 2016):

nevermind, I just reproduced the crash (weird, it happens only on second execution)

@JohnEstropia commented on GitHub (Sep 23, 2016): nevermind, I just reproduced the crash (weird, it happens only on second execution)

adam commented

2025-12-29 15:24:06 +01:00

@JohnEstropia commented on GitHub (Sep 23, 2016):

I might have a hunch on why this is happening. Let me test for a while

@JohnEstropia commented on GitHub (Sep 23, 2016): I might have a hunch on why this is happening. Let me test for a while

adam commented

@JohnEstropia commented on GitHub (Sep 23, 2016):

My hunch was correct, but I hit a roadblock. First, using @jamesbebbington's test project, go to CoreStoreFetchRequest.swift and comment out the override for affectedStores

// MARK: - CoreStoreFetchRequest

// Bugfix for NSFetchRequest messing up memory management for `affectedStores`
// http://stackoverflow.com/questions/14396375/nsfetchedresultscontroller-crashes-in-ios-6-if-affectedstores-is-specified
internal final class CoreStoreFetchRequest: NSFetchRequest {

//    @objc
//    override var affectedStores: [NSPersistentStore]? {
//        
//        get { return super.affectedStores }
//        set { super.affectedStores = newValue }
//    }
}

This fixed the crash for me. Here's the problem: doing this breaks CoreStore's unit tests and demo app. The difference I can think of is that the test project imports CoreStore as a Cocoapod, and CoreStore's test cases and demo app imports it as a framework. There must be a Cocoapod compiler setting somewhere that somehow fixes the bug that override var affectedStores was trying to fix.

I'll continue investigating this tomorrow, but if you find other hints please do share. In the meantime, you can try commenting out the code above.

@JohnEstropia commented on GitHub (Sep 23, 2016): My hunch was correct, but I hit a roadblock. First, using @jamesbebbington's test project, go to **CoreStoreFetchRequest.swift** and comment out the override for `affectedStores` ``` swift // MARK: - CoreStoreFetchRequest // Bugfix for NSFetchRequest messing up memory management for `affectedStores` // http://stackoverflow.com/questions/14396375/nsfetchedresultscontroller-crashes-in-ios-6-if-affectedstores-is-specified internal final class CoreStoreFetchRequest: NSFetchRequest { // @objc // override var affectedStores: [NSPersistentStore]? { // // get { return super.affectedStores } // set { super.affectedStores = newValue } // } } ``` This fixed the crash for me. Here's the problem: doing this breaks CoreStore's unit tests and demo app. The difference I can think of is that the test project imports CoreStore as a Cocoapod, and CoreStore's test cases and demo app imports it as a framework. There must be a Cocoapod compiler setting somewhere that somehow fixes the bug that `override var affectedStores` was trying to fix. I'll continue investigating this tomorrow, but if you find other hints please do share. In the meantime, you can try commenting out the code above.

adam commented

2025-12-29 15:24:06 +01:00

@laeroah commented on GitHub (Sep 23, 2016):

I can verify the workaround. Thank you so much.

@laeroah commented on GitHub (Sep 23, 2016): I can verify the workaround. Thank you so much.

adam commented

2025-12-29 15:24:06 +01:00

@laeroah commented on GitHub (Sep 26, 2016):

@JohnEstropia hey, I'm a little confused about how the queues are handled.
In beginAsynchronous, when the closure is performed, it is using self.transactionQueue.async, and execute the closure in one serial queue "com.corestore.datastack.childtransactionqueue".
Now, shouldn't the closure be performed in performBlock of the transaction's managed context? since inside the closure, we suppose use the transaction to do stuff on managed objects in the transaction's context.
I believe this is why multithread violation exception is being called by the xcode. I could be wrong, but hope this would be helpful information to fix the crashes.
Currently using CoreStore on a project, which has a tight deadline. :(

@laeroah commented on GitHub (Sep 26, 2016): @JohnEstropia hey, I'm a little confused about how the queues are handled. In `beginAsynchronous`, when the closure is performed, it is using `self.transactionQueue.async`, and execute the closure in one serial queue "com.corestore.datastack.childtransactionqueue". Now, shouldn't the closure be performed in `performBlock` of the transaction's managed context? since inside the closure, we suppose use the transaction to do stuff on managed objects in the transaction's context. I believe this is why multithread violation exception is being called by the xcode. I could be wrong, but hope this would be helpful information to fix the crashes. Currently using CoreStore on a project, which has a tight deadline. :(

adam commented

2025-12-29 15:24:07 +01:00

@JohnEstropia commented on GitHub (Sep 26, 2016):

@laeroah
There has been many inquiries regarding why CoreStore doesn't use the context's performBlock:

As explained in the previous threads, CoreStore manages the queueing on the architecture level (transactions), not on the data level (performBlock). As such, debugging with com.apple.CoreData.ConcurrencyDebug is really not required. This is explicitly mentioned in the README: https://github.com/JohnEstropia/CoreStore#installation

As for the crash in question, I assure you this has nothing to do with threading, but with a long standing bug with the NSFetchRequest.affectedStores property: http://stackoverflow.com/questions/14396375/nsfetchedresultscontroller-crashes-in-ios-6-if-affectedstores-is-specified

CoreStore fixed this in pre-iOS 10 by subclassing NSFetchRequest, but with iOS 10 the previous workaround seems to not work anymore.

I understand this is affecting your project, but so far I haven't found a work around that fixes the bug. In the meantime, If you are just using

From<YourEntity>()

instead of

From<YourEntity>("configuration")

in your From clauses, I can provide a temporary branch you can use with your project. I'll test if it runs fine on iOS 10 and notify you if it works as soon as I can.

@JohnEstropia commented on GitHub (Sep 26, 2016): @laeroah There has been many inquiries regarding why CoreStore doesn't use the context's `performBlock`: - https://github.com/JohnEstropia/CoreStore/issues/28 - https://github.com/JohnEstropia/CoreStore/issues/60 - https://github.com/JohnEstropia/CoreStore/issues/79 As explained in the previous threads, CoreStore manages the queueing on the architecture level (transactions), not on the data level (`performBlock`). As such, debugging with `com.apple.CoreData.ConcurrencyDebug` is really not required. This is explicitly mentioned in the README: https://github.com/JohnEstropia/CoreStore#installation As for the crash in question, I assure you this has nothing to do with threading, but with a long standing bug with the `NSFetchRequest.affectedStores` property: http://stackoverflow.com/questions/14396375/nsfetchedresultscontroller-crashes-in-ios-6-if-affectedstores-is-specified CoreStore fixed this in pre-iOS 10 by [subclassing NSFetchRequest](https://github.com/JohnEstropia/CoreStore/blob/develop/Sources/Internal/CoreStoreFetchRequest.swift#L33), but with iOS 10 the previous workaround seems to not work anymore. I understand this is affecting your project, but so far I haven't found a work around that fixes the bug. In the meantime, If you are just using ``` swift From<YourEntity>() ``` instead of ``` swift From<YourEntity>("configuration") ``` in your `From` clauses, I can provide a temporary branch you can use with your project. I'll test if it runs fine on iOS 10 and notify you if it works as soon as I can.

adam commented

2025-12-29 15:24:07 +01:00

@JohnEstropia commented on GitHub (Sep 26, 2016):

@laeroah May I ask how you installed CoreStore in your project? Do you use Cocoapods?
If so, can you try to import CoreStore using Carthage or using git submodule and see if this crash still occurs?

I cannot reproduce this bug with Swift 2.3 projects that builds CoreStore's framework project so you might have some luck with it.

@JohnEstropia commented on GitHub (Sep 26, 2016): @laeroah May I ask how you installed CoreStore in your project? Do you use Cocoapods? If so, can you try to import CoreStore using Carthage or using git submodule and see if this crash still occurs? I cannot reproduce this bug with Swift 2.3 projects that builds CoreStore's framework project so you might have some luck with it.

adam commented

@jamesbebbington commented on GitHub (Sep 26, 2016):

@JohnEstropia said:

…In the meantime, you can try commenting out the code above.

Yup, if I comment out the affectedStores override, my app no longer crashes.

@jamesbebbington commented on GitHub (Sep 26, 2016): @JohnEstropia said: > …In the meantime, you can try commenting out the code above. Yup, if I comment out the `affectedStores` override, my app no longer crashes.

adam commented

@JohnEstropia commented on GitHub (Sep 26, 2016):

@jamesbebbington You may need to check certain cases because there seem to be some cases where the fix above just propagates the crash to a different time. See https://github.com/JohnEstropia/CoreStore/issues/101

Please also try if importing CoreStore via Carthage or git submodule instead of Cocoapods can fix the problem for you.

@JohnEstropia commented on GitHub (Sep 26, 2016): @jamesbebbington You may need to check certain cases because there seem to be some cases where the fix above just propagates the crash to a different time. See https://github.com/JohnEstropia/CoreStore/issues/101 Please also try if importing CoreStore via Carthage or git submodule instead of Cocoapods can fix the problem for you.

adam commented

@laeroah commented on GitHub (Sep 26, 2016):

@JohnEstropia I have tried copy all CoreStore and GCD code directly into a project, but still it crashes. I'm only using From(). Didn't use multiple configurations. thank you.

@laeroah commented on GitHub (Sep 26, 2016): @JohnEstropia I have tried copy all CoreStore and GCD code directly into a project, but still it crashes. I'm only using From<YourEntity>(). Didn't use multiple configurations. thank you.

adam commented

@JohnEstropia commented on GitHub (Sep 26, 2016):

@laeroah @jamesbebbington Sorry for the long wait! Please try the develop branch if it fixes the problem for you.

Workaround: 4d2ebe4ea8 (diff-5b788f6d8b8b55c6c042f1f510bf673cR234)

@JohnEstropia commented on GitHub (Sep 26, 2016): @laeroah @jamesbebbington Sorry for the long wait! Please try the `develop` branch if it fixes the problem for you. Workaround: https://github.com/JohnEstropia/CoreStore/commit/4d2ebe4ea8875bbacc7435124bb87c9708d1c35b#diff-5b788f6d8b8b55c6c042f1f510bf673cR234

adam commented

2025-12-29 15:24:09 +01:00

@laeroah commented on GitHub (Sep 27, 2016):

worked! thanks!

@laeroah commented on GitHub (Sep 27, 2016): worked! thanks!

adam commented

@JohnEstropia commented on GitHub (Sep 27, 2016):

Whew, thats great :) Hopefully this bug won't bite us again in a future iOS update... Will update the master branch and the Cococapods trunk later within the day. (Please wait for version 2.1.1)

@laeroah and @jamesbebbington, thanks for all the feedback. It was a great help :)

@JohnEstropia commented on GitHub (Sep 27, 2016): Whew, thats great :) Hopefully this bug won't bite us again in a future iOS update... Will update the master branch and the Cococapods trunk later within the day. (Please wait for version 2.1.1) @laeroah and @jamesbebbington, thanks for all the feedback. It was a great help :)

adam commented

2025-12-29 15:24:09 +01:00

@jamesbebbington commented on GitHub (Sep 27, 2016):

You're welcome @JohnEstropia. Thanks for the fix!

@jamesbebbington commented on GitHub (Sep 27, 2016): You're welcome @JohnEstropia. Thanks for the fix!

adam commented

2025-12-29 15:24:09 +01:00

@laeroah commented on GitHub (Sep 27, 2016):

Thank you!

@laeroah commented on GitHub (Sep 27, 2016): Thank you!

adam commented

@a13xb commented on GitHub (Feb 27, 2019):

I am running into the exact same issue right now (Xcode 10.1, Swift 4, CoreStore 6.1, running on iOS 10). However any previous workarounds mentioned here appear to have been removed (CoreStoreFetchRequest removed entirely in eeec3979). Was there a rationale for this? (new workaround, no workaround necessary, something else)

@a13xb commented on GitHub (Feb 27, 2019): I am running into the _exact_ same issue right now (Xcode 10.1, Swift 4, CoreStore 6.1, running on iOS 10). However any previous workarounds mentioned here appear to have been removed (`CoreStoreFetchRequest` removed entirely in eeec3979). Was there a rationale for this? (new workaround, no workaround necessary, something else)

adam commented

@JohnEstropia commented on GitHub (Feb 27, 2019):

@a13xb Hi, is your project and CoreStore being compiled as Swift 4.2? If not, please use the 5.x version for now and let me know if you still see the issues

@JohnEstropia commented on GitHub (Feb 27, 2019): @a13xb Hi, is your project and CoreStore being compiled as Swift 4.2? If not, please use the 5.x version for now and let me know if you still see the issues

adam commented

@a13xb commented on GitHub (Feb 27, 2019):

Yes it's compiled with Swift 4.2. I'll give 5.x a shot.

@a13xb commented on GitHub (Feb 27, 2019): Yes it's compiled with Swift 4.2. I'll give 5.x a shot.

adam commented

@JohnEstropia commented on GitHub (Feb 28, 2019):

@a13xb Please let me know if 5.x works for you. As for the rationale of eeec3979ee, I've had a suite of use-cases (Including https://github.com/JohnEstropia/CoreStore/issues/100#issuecomment-249223584) that broke without the workaround. With the latest Swift version I've found them working even without the CoreStoreFetchRequest workaround so assumed it's been fixed.

In that regard, it does mean the tests I've been doing until now are not reliable anymore so if anyone can provide an isolated case for this new issue It'd be a great help.

@JohnEstropia commented on GitHub (Feb 28, 2019): @a13xb Please let me know if 5.x works for you. As for the rationale of https://github.com/JohnEstropia/CoreStore/commit/eeec3979eec60210987445de4b595e8ec249c934, I've had a suite of use-cases (Including https://github.com/JohnEstropia/CoreStore/issues/100#issuecomment-249223584) that broke without the workaround. With the latest Swift version I've found them working even without the `CoreStoreFetchRequest` workaround so assumed it's been fixed. In that regard, it does mean the tests I've been doing until now are not reliable anymore so if anyone can provide an isolated case for this new issue It'd be a great help.

adam commented

2025-12-29 15:24:11 +01:00

@a13xb commented on GitHub (Feb 28, 2019):

CoreStore	iOS 10	iOS 12
6.x	crash	no crash
5.x	no crash	no crash

@a13xb commented on GitHub (Feb 28, 2019): | CoreStore | iOS 10 | iOS 12 | | :--- | :--- | :--- | | 6.x | crash | no crash | | 5.x | no crash | no crash |

adam commented

@JohnEstropia commented on GitHub (Feb 28, 2019):

Oh boy 😅
@a13xb Thanks for testing this out! I'll try to get a fix up in the next update

@JohnEstropia commented on GitHub (Feb 28, 2019): Oh boy 😅 @a13xb Thanks for testing this out! I'll try to get a fix up in the next update

adam commented

2025-12-29 15:24:11 +01:00

@JohnEstropia commented on GitHub (Feb 28, 2019):

@a13xb Reverted some changes in CoreStore 6.2.0. Let me know if there are further issues

@JohnEstropia commented on GitHub (Feb 28, 2019): @a13xb Reverted some changes in CoreStore 6.2.0. Let me know if there are further issues

adam commented

@a13xb commented on GitHub (Feb 28, 2019):

Still the same crash, unfortunately.

I have tested with 5b365c64 (one before eeec397), and it does not crash, which leads me to believe it's regressed precisely in eeec397 (the removal of CoreStoreFetchRequest).

@a13xb commented on GitHub (Feb 28, 2019): Still the same crash, unfortunately. I have tested with 5b365c64 (one before eeec397), and it does not crash, which leads me to believe it's regressed precisely in eeec397 (the removal of `CoreStoreFetchRequest`).

adam commented

@JohnEstropia commented on GitHub (Feb 28, 2019):

@a13xb Please try the latest develop branch and let me know how it goes

@JohnEstropia commented on GitHub (Feb 28, 2019): @a13xb Please try the latest `develop` branch and let me know how it goes

adam commented

@a13xb commented on GitHub (Feb 28, 2019):

Yep, that fixes it. 👍

@a13xb commented on GitHub (Feb 28, 2019): Yep, that fixes it. 👍

adam commented