-
Notifications
You must be signed in to change notification settings - Fork 608
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
ocmock tests have problems with Xcode 13.0b2 on iOS15 #501
Comments
dmaclach
added a commit
to dmaclach/ocmock
that referenced
this issue
Jul 9, 2021
Partial fix for erikdoe#501. Wraps up a bunch of locations with synchronization blocks to attempt to make sure that the class is coherent before it starts receiving messages.
dmaclach
added a commit
to dmaclach/ocmock
that referenced
this issue
Jul 9, 2021
Partial fix for erikdoe#501. Wraps up a bunch of locations with synchronization blocks to attempt to make sure that the class is coherent before it starts receiving messages.
Repository owner
deleted a comment from
hgoyal6
Oct 26, 2021
I can reproduce this problem. Will look into it. |
4 tasks
It is reproducible on ARM Macs as well. When running natively, the error is like @dmaclach provided.
|
I'm seeing the same issue while running against Xcode 15. while I can't repro this locally, but in our pipeline this occurs sometimes. Is there a fix that went earlier where I can track? cc @erikdoe |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If I open b9c7fb9 in Xcode 13 and execute the tests on an iOS15 simulator multiple times, I eventually get a crash in something like:
It appears that Apple now uses a separate thread to deal with debug logs
Thread 6 Queue : com.apple.dt.xctest.default-debug-log-handler (serial)
which assumes that the NSNumber and NSMutableData classes aren't going to be messed with.
This exposes a bunch of potential race conditions we have:
If stopMockingClassMethods executes before point >>>1, mock will be nil and the exception will fire.
If stopMockingClassMethods executes between >>>1 and >>>2 and the mock is dealloc'd, the invocation to mock will fail.
if stopMockingClassMethods executes between >>>1 and >>>2, the class will have been changed and the selector will not be recognized (this is likely what happened in the crash log scenario above).
Also, if a class method gets called while the mock is being set up in prepareClassForClassMethodMocking, we also run into problems.
The text was updated successfully, but these errors were encountered: