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

editingTransactionQueueBusy = YES, but _editingTransactionGroupCount = 0 #914

Closed
haashem opened this issue May 8, 2018 · 4 comments
Closed
Assignees

Comments

@haashem
Copy link

haashem commented May 8, 2018

I'm using latest version of Texture cloned from GitHub.
but occasionally I face this strange issue:

'NSInternalInconsistencyException', reason: 'editingTransactionQueueBusy = YES, but _editingTransactionGroupCount = 0 !'

any Idea whats going on?

screen shot 2018-05-08 at 2 53 42 pm

screen shot 2018-05-08 at 2 53 43 pm

@appleguy
Copy link
Member

@hashemp206 I have an idea for how this is happening. Could you "bt all" if you can trigger this again? Specifically I need to see what the other threads are doing, to understand if it is possible that one of them has just decremented the Count variable but a block is still running.

If you could also log out the values for Busy and Count at the time of the assert, that might be enough to create a theoretical fix.

@appleguy appleguy self-assigned this May 13, 2018
@haashem
Copy link
Author

haashem commented May 13, 2018

@appleguy I tried hard now to reproduce it but doesn't happen right now! I will try more

@haashem
Copy link
Author

haashem commented May 14, 2018

@appleguy today it happened, accidentally one more time after application launch:
count is 0 and busy is Yes

screen shot 2018-05-08 at 2 53 43 pm

screen shot 2018-05-08 at 2 53 43 pm

Adlai-Holler pushed a commit that referenced this issue May 17, 2018
* fix SIMULATE_WEB_RESPONSE not imported #449

* Fix to make rangeMode update in right time

* remove uncessary assert
@appleguy
Copy link
Member

@hashemp206 thanks again for reporting this. We found out that, ironically, this assertion was invalid even though the code was valid. That is to say, the assertion required transactional integrity between two bits of state (the atomic counter, and the queue), which is actually not required if only the counter is being referenced. So, all should be well if you update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants