Application Crashes when accessing attribute of a record #197

New Issue

Closed

opened 2025-12-29 15:26:30 +01:00 by adam · 4 comments

adam commented 2025-12-29 15:26:30 +01:00

Owner

Copy Link

Copy Source

Originally created by @ujamshy on GitHub (Feb 5, 2018).

Hi, I need your help with a problem that causes our application to crash.
The crash is happening at customers` devices - we couldn't reproduce it on our tests

Architecture:
The relevant table in the database contains log records.
LogManager contains a DataStack and uses it to create/insert/update/delete log records.
LogObserver uses ListMonitor to get notifications about changes to the table and communicates these changes to a remote server.
It runs in its own serial queue and uses un UnsafeTransaction created from the DataStack to handle managed objects.
When it gets a notification about a new/updated object (didInsertObject/didUpdateObject) it performs the following code:

open func listMonitor(_ monitor: ListMonitor<M>, didInsertObject object: M, toIndexPath indexPath: IndexPath) {

    self.localQueue.async {

        // using its UnsafeTransaction to fetch the object
        guard let existingObject = self.transaction.fetchExisting(object) else { return }
        existingObject.refreshAndMerge()
        // handle the object
        self.handlePendingObject(existingObject)
    }
}

LogObserver's transaction is created in its own queue the first time it is used:

lazy var transaction: UnsafeDataTransaction = {

    let transaction = self.dataStack.beginUnsafe()

    return transaction
}()

When handling an object we try to check if it is deleted by testing if its context is nil:

func handlePendingObject(_ object: M) {
   ...

    // test if object was deleted
    if object.managedObjectContext == nil {

        return
    }
}

Crash:
The crash happens sometimes when a record is deleted from the DataStack while still held by the LogObserver.
When printing the record all its attributes are displayed as nil (although they are not optionals).
When trying to access one of the attributes the application crashes with Exception Type: SIGTRAP.

Questions:
I have several questions:

1. Do we use correctly the UnsafeTransaction?
2. Is there a better test for deleted object?
3. Can you suggest a way to avoid the crash?

Thanks :)

Originally created by @ujamshy on GitHub (Feb 5, 2018). Hi, I need your help with a problem that causes our application to crash. The crash is happening at customers` devices - we couldn't reproduce it on our tests **Architecture:** The relevant table in the database contains log records. **LogManager** contains a DataStack and uses it to create/insert/update/delete log records. **LogObserver** uses ListMonitor to get notifications about changes to the table and communicates these changes to a remote server. It runs in its own serial queue and uses un UnsafeTransaction created from the DataStack to handle managed objects. When it gets a notification about a new/updated object (didInsertObject/didUpdateObject) it performs the following code: ``` open func listMonitor(_ monitor: ListMonitor<M>, didInsertObject object: M, toIndexPath indexPath: IndexPath) { self.localQueue.async { // using its UnsafeTransaction to fetch the object guard let existingObject = self.transaction.fetchExisting(object) else { return } existingObject.refreshAndMerge() // handle the object self.handlePendingObject(existingObject) } } ``` **LogObserver**'s transaction is created in its own queue the first time it is used: ``` lazy var transaction: UnsafeDataTransaction = { let transaction = self.dataStack.beginUnsafe() return transaction }() ``` When handling an object we try to check if it is deleted by testing if its context is nil: ``` func handlePendingObject(_ object: M) { ... // test if object was deleted if object.managedObjectContext == nil { return } } ``` **Crash**: The crash happens sometimes when a record is deleted from the DataStack while still held by the LogObserver. When printing the record all its attributes are displayed as nil (although they are not optionals). When trying to access one of the attributes the application crashes with Exception Type: SIGTRAP. **Questions**: I have several questions: 1. Do we use correctly the UnsafeTransaction? 2. Is there a better test for deleted object? 3. Can you suggest a way to avoid the crash? Thanks :)

adam added the question label 2025-12-29 15:26:30 +01:00

adam closed this issue 2025-12-29 15:26:30 +01:00

adam commented 2025-12-29 15:26:30 +01:00

Author

Owner

Copy Link

Copy Source

@JohnEstropia commented on GitHub (Feb 8, 2018):

CoreStore's transactions are designed more for updating data than observing for updates. There will be a hiccup with your DataStack-to-Transaction synchronization because of the changes propagating in different queues. My suggestion here would be to try using a ListMonitor created from the UnsafeDataTransaction and observe that directly.

That said, I haven't personally used a ListMonitor created from an UnsafeDataTransaction in my projects (although I know some users who had) so I cannot offer advices against existing pitfalls, if there are any.

If you have the luxury of redesigning your architecture, I strongly recommend you reduce the granularity of your transactions and to use perform(asynchronous:...) and perform(synchronous:) when you can. There is a reason that CoreStore's Async and Sync transactions execute serially: they protect you from synchronization issues like these by not having to worry about changes in parallel transactions.

@JohnEstropia commented on GitHub (Feb 8, 2018): CoreStore's transactions are designed more for updating data than observing for updates. There will be a hiccup with your DataStack-to-Transaction synchronization because of the changes propagating in different queues. My suggestion here would be to try using a `ListMonitor` created from the `UnsafeDataTransaction` and observe that directly. That said, I haven't personally used a `ListMonitor` created from an `UnsafeDataTransaction` in my projects (although I know some users who had) so I cannot offer advices against existing pitfalls, if there are any. If you have the luxury of redesigning your architecture, I strongly recommend you reduce the granularity of your transactions and to use `perform(asynchronous:...)` and `perform(synchronous:)` when you can. There is a reason that CoreStore's Async and Sync transactions execute serially: they protect you from synchronization issues like these by not having to worry about changes in parallel transactions.

adam commented 2025-12-29 15:26:31 +01:00

Author

Owner

Copy Link

Copy Source

@ujamshy commented on GitHub (Feb 8, 2018):

Let me refine my question. Suppose we have DataStack and UnsafeTransaction derived from the DataStack. Suppose also that an object in the DataStack and was added to the unsafe transaction using featchExisting. If the object is deleted from the DataStack should accessing it in the UnsafeTransaction cause exception?

@ujamshy commented on GitHub (Feb 8, 2018): Let me refine my question. Suppose we have DataStack and UnsafeTransaction derived from the DataStack. Suppose also that an object in the DataStack and was added to the unsafe transaction using featchExisting. If the object is deleted from the DataStack should accessing it in the UnsafeTransaction cause exception?

adam commented 2025-12-29 15:26:31 +01:00

Author

Owner

Copy Link

Copy Source

@JohnEstropia commented on GitHub (Feb 15, 2018):

@ujamshy That's more of Core Data's behavior than anything, and yes that may trigger an exception.

@JohnEstropia commented on GitHub (Feb 15, 2018): @ujamshy That's more of Core Data's behavior than anything, and yes that may trigger an exception.

adam commented 2025-12-29 15:26:31 +01:00

Author

Owner

Copy Link

Copy Source

@JohnEstropia commented on GitHub (Apr 14, 2018):

I'm closing this issue as this is Core Data's behavior. Let me know if you find a resolution so we can put a warning somewhere in the README.

@JohnEstropia commented on GitHub (Apr 14, 2018): I'm closing this issue as this is Core Data's behavior. Let me know if you find a resolution so we can put a warning somewhere in the README.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

develop

prototype/swift6

master

prototype/concurrency

minIOS13

prototype/containers

transactionSourceTracking

prototype/swiftui

minIOS11

swift5_3

prototype/propertyWrapperFields

prototype/propertyWrappers

prototype/propertyWrapper

Swift5

throwables

prototype/Swift_4_1

prototype/Swift_4_0

prototype/Swift_3_2

prototype/queryBuilders

temp/develop

corestore4_develop

prototype/mainContextToPSC

master_ios_7_to_9

swift_2_3

gh-pages

_corespotlight-test

9.3.0

9.2.0

9.1.0

9.0.0

8.1.0

8.0.1

8.0.0

7.3.1

7.3.0

7.2.0

7.1.0

7.0.4

7.0.3

7.0.2

7.0.1

7.0.0

6.3.2

6.3.1

6.3.0

6.2.1

6.2.0

6.1.0

6.0.0

5.3.1

5.3.0

5.2.0

5.1.1

5.1.0

5.0.0

4.2.4

4.2.3

4.2.2

4.2.1

4.2.0

4.1.4

4.1.3

4.1.1

4.1.0

4.0.5

4.0.4

4.0.3

4.0.2

4.0.1

4.0.0

4.0.0-beta3

4.0.0-beta2

4.0.0-beta

3.1.1

3.1.0

3.0.3

3.0.2

3.0.1

3.0.0

2.1.3

2.1.2

2.1.1

2.1.0

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

1.6.10

1.6.9

1.6.8

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.1

1.2.0

1.0.2

1.0.1

1.0.0

0.2.1

0.2.0

0.1.2

0.1.1

0.1.0

Labels

Clear labels

abandoned

corestore bug

discussion

duplicate

enhancement

fixed

fixed

help wanted

in progress

investigating

ios/compiler bug

irreproducible

looking for workarounds

not a bug

pending

pending docs update

pull-request

Mirrored from GitHub Pull Request

question

regression

user bug

wontfix

No labels question

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

adam (Adam Melkus)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/CoreStore#197