My application crashes each and every time I try to step over a call. Without debugger it works fine.
Also, when I run the app in simulator it woks fine with or without debugger.
Recently I upgraded my Mac OS X 10.8 to 10.9 (Mavericks). There were no issues before the upgrade.
What causes the issue and how could I fix it?
Below is the back trace. My app uses ARC. I have enabled zombies and added exception breakpoint but no zombies where detected and exception breakpoint is never triggered.
* thread #1: tid = 0x2503, 0x00000000, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x00000000
frame #1: 0x35e170c4 UIKit`-[UIApplication sendAction:to:from:forEvent:] + 72
frame #2: 0x35e17076 UIKit`-[UIApplication sendAction:toTarget:fromSender:forEvent:] + 30
frame #3: 0x35e17054 UIKit`-[UIControl sendAction:to:forEvent:] + 44
frame #4: 0x35e1690a UIKit`-[UIControl(Internal) _sendActionsForEvents:withEvent:] + 502
frame #5: 0x35e16e00 UIKit`-[UIControl touchesEnded:withEvent:] + 488
frame #6: 0x35d3f5f0 UIKit`-[UIWindow _sendTouchesForEvent:] + 524
frame #7: 0x35d2c800 UIKit`-[UIApplication sendEvent:] + 380
frame #8: 0x35d2c11a UIKit`_UIApplicationHandleEvent + 6154
frame #9: 0x37a1e5a2 GraphicsServices`_PurpleEventCallback + 590
frame #10: 0x37a1e1d2 GraphicsServices`PurpleEventCallback + 34
frame #11: 0x33ef9172 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 34
frame #12: 0x33ef9116 CoreFoundation`__CFRunLoopDoSource1 + 138
frame #13: 0x33ef7f98 CoreFoundation`__CFRunLoopRun + 1384
frame #14: 0x33e6aebc CoreFoundation`CFRunLoopRunSpecific + 356
frame #15: 0x33e6ad48 CoreFoundation`CFRunLoopRunInMode + 104
frame #16: 0x37a1d2ea GraphicsServices`GSEventRunModal + 74
frame #17: 0x35d80300 UIKit`UIApplicationMain + 1120
frame #18: 0x000faac8 MyApp`main(argc=1, argv=0x2fd0fd08) + 116 at main.m:16
EDIT:
I have latest Xcode Version 5.0.1 (5A2053).
I have created new app from scratch and ran it without issues. Then I put a breakpoint in ViewController's viewDidLoad and tried to step over. Here I got another crash
* thread #1: tid = 0x2503, 0x3bb9d7c4 libobjc.A.dylib`objc_msgSendSuper2 + 4, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x4)
frame #0: 0x3bb9d7c4 libobjc.A.dylib`objc_msgSendSuper2 + 4
frame #1: 0x000b913a test`-[ViewController viewDidLoad](self=0x1cda5c70, _cmd=0x361bd5db) + 62 at ViewController.m:19
frame #2: 0x35d4b594 UIKit`-[UIViewController loadViewIfRequired] + 364
frame #3: 0x35d8bd78 UIKit`-[UIWindow addRootViewControllerViewIfPossible] + 64
frame #4: 0x35d87aec UIKit`-[UIWindow _setHidden:forced:] + 364
frame #5: 0x35dc91e8 UIKit`-[UIWindow makeKeyAndVisible] + 60
frame #6: 0x35d8c83e UIKit`-[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 1666
frame #7: 0x35d8484a UIKit`-[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 698
frame #8: 0x35d2cc38 UIKit`-[UIApplication handleEvent:withNewEvent:] + 1004
frame #9: 0x35d2c6cc UIKit`-[UIApplication sendEvent:] + 72
frame #10: 0x35d2c11a UIKit`_UIApplicationHandleEvent + 6154
frame #11: 0x37a1e5a2 GraphicsServices`_PurpleEventCallback + 590
frame #12: 0x37a1e1d2 GraphicsServices`PurpleEventCallback + 34
frame #13: 0x33ef9172 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 34
frame #14: 0x33ef9116 CoreFoundation`__CFRunLoopDoSource1 + 138
frame #15: 0x33ef7f98 CoreFoundation`__CFRunLoopRun + 1384
frame #16: 0x33e6aebc CoreFoundation`CFRunLoopRunSpecific + 356
frame #17: 0x33e6ad48 CoreFoundation`CFRunLoopRunInMode + 104
frame #18: 0x35d83484 UIKit`-[UIApplication _run] + 668
frame #19: 0x35d80300 UIKit`UIApplicationMain + 1120
frame #20: 0x000b93bc test`main(argc=1, argv=0x2fd51d30) + 116 at main.m:16
frame #21: 0x3bfd9b20 libdyld.dylib`start + 4
EDIT 2:
Greg Clayton in the XCode 5 Crashes while running the app on device suggests following
Others have seen this issue.
A few things to try:
1 - Reboot your device and try again. The theory is an old developer disk image is already mounted and won't be unmounted until you reboot.
2 - Re-install the OS on the device
Hopefully #1 fixes your issue. Others have done #2 and had their issue fixed, but hopefully it doesn't require an OS re-install.
I did both and it didn't help.
I tried to use another device and it made a difference. Exceptions are still there if I use iPod Touch with iOS 6.1 but iPad with iOS 7.0.2 works fine.
So, it looks like the issue is related to the iOS version installed on the device. I am still not sure what to do to fix it.
EDIT 3:
My Command Line Tools version matches my Xcode version (I have only one version of Command Line Tools, actually).
The issues is probably not related to the code being debugged. It crashes with newly created Single View Application created by Xcode. And it crashes when stepping over trivial code:
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
}
I have asked on Apple Developer Forum and got following response from Jason Molenda:
We're tracking a bug that sounds like what you're seeing here. It is
a subtle timing issue that requires a slightly slower host machine or
a slightly slower device to hit. It is primarily iPhone 4 and similar
that will see this with iOS 7. With iOS 6, iPhone 4 and iPhone 3GS
devices are most likely to experience it. ... This issue will only
happen with Xcode 5.0.1.
So, it seems like it's a bug in Xcode.
Ok, this is definitely a bug in Xcode 5.0.1.
This is confirmed by Jason Molenda on Apple Developer Forum. The only workaround for now is to use older version of Xcode and the older version of Mac OS X because Xcode 5 requires OS X 10.8.4.
There is no announced ETA for a fix for this issue. Direct question about ETA on Apple Developer Forum is left without answer.
UPDATE 06-Nov-2013:
Today a pre-release version of Xcode 5.0.2 became available on developer.apple.com. This version fixes (among other things) the following issue:
Debugging an application on a device running iOS 6.x causes the
application to crash with EXC_BAD_ACCESS. This has been resolved.
(15310896)
I have installed the new version and the issue is indeed gone. Now I am able to debug apps on my 6.x devices again.
Jason Molenda in thread on Apple Developer Forum said:
I'm told you can submit apps to the app store with this Xcode 5.0.2
seed.
I confirm I have exactly same bug. My App worked fine.
After upgrade to Xcode 5 and Mavericks code work but when I debug I can't Step Over certain lines as I get EXC_BAD_ACCESS.
So I have to remember lines that I can't pass with Step Over and put break point after these lines or use Continue to Line to jump over these problematic lines.
PS
Downloaded Xcode 5.0.2 GM seed and debugging is much better. I spent 30 minutes with new Xcode so far.
Please login developer site and download the Xcode 5.0.2 GM seed, it fixed this bug.
See the release notes.
Update 12-Nov-2013
Xcode 5.0.2 has released, you can download it from Dev Center
Related
The following code exports a file from my app's 'tmp' folder to other apps using UIActivityViewController.
private func exportFile(_ fileURL: URL) {
let items: [Any] = [fileURL]
let activityViewController = UIActivityViewController(activityItems: items, applicationActivities: nil)
present(activityViewController, animated: true, completion: nil)
}
This code was working fine and I could export to iCloud, Google Drive, Mail, Outlook and iZip (the latter using 'Copy to iZip').
However, my app has recently started crashing after selecting 'Copy to iZip' when exporting, though exporting to the other apps works fine. Between it working and crashing there have been updates to iOS, iZip and my app.
Crashlytics reports the following, but this looks deep in iOS and it's difficult to know what the root cause of the problem is:
Fatal Exception: NSInvalidArgumentException
*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil
ShareSheet __79-[UIActivityViewController willPerformInServiceActivityWithRequest:completion:]_block_invoke_3
This occurs on an iPhone running iOS 13.3.1
Debugger report on breaking on NSInvalidArgumentException:
> (lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000189ffdf6c libobjc.A.dylib`objc_exception_throw
frame #1: 0x000000018a32c360 CoreFoundation`_CFThrowFormattedException + 112
frame #2: 0x000000018a32b9f4 CoreFoundation`-[__NSArrayM insertObject:atIndex:].cold.1 + 48
frame #3: 0x000000018a1ae120 CoreFoundation`-[__NSArrayM insertObject:atIndex:] + 1104
frame #4: 0x0000000195914e80 ShareSheet`__79-[UIActivityViewController willPerformInServiceActivityWithRequest:completion:]_block_invoke_3 + 1512
frame #5: 0x00000001089497fc libdispatch.dylib`_dispatch_call_block_and_release + 24
frame #6: 0x000000010894abd8 libdispatch.dylib`_dispatch_client_callout + 16
frame #7: 0x0000000108958c34 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 1316
frame #8: 0x000000018a2545e4 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
frame #9: 0x000000018a24f5d8 CoreFoundation`__CFRunLoopRun + 2004
frame #10: 0x000000018a24eadc CoreFoundation`CFRunLoopRunSpecific + 464
frame #11: 0x00000001941ef328 GraphicsServices`GSEventRunModal + 104
frame #12: 0x000000018e35c63c UIKitCore`UIApplicationMain + 1936
* frame #13: 0x00000001024f1078 xApp`main at AppDelegate.swift:41:7
frame #14: 0x000000018a0d8360 libdyld.dylib`start + 4
(lldb)
Code at frame #4 breakpoint (0x195914e80):
> WTFLogLevel, WTF::Logger::LogSiteIdentifier const&, char const (&) [7], unsigned long const&) (.cold.1)
0x195914e80 <+1512>: mov x28, x23
0x195914e84 <+1516>: ldr x0, [x23, #0xba0]
0x195914e88 <+1520>: ldr x1, [sp, #0x38]
0x195914e8c <+1524>: mov x2, x25
0x195914e90 <+1528>: mov x3, x20
0x195914e94 <+1532>: bl 0x193904be4 ; symbol stub
Any idea what the problem might be? I'm not sure whether it's a problem with my app, iOS or iZip.
Thanks to the suggestion from #koen, I contacted iZip support and had a very quick and helpful response. It also ties in with #WILL K. 's suggestion of trying a different directory.
The problem basically seems to be associated with directory permissions. Apparently some apps like iZip open the shared file in situ and so need permission to do so. As can be seen here https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html , the Documents/ directory "can be made available to the user through file sharing" whereas the tmp/ directory is more restricted.
So instead of using the tmp/ directory I tried using the Documents/ directory and the problem was solved. Thanks to iZip support for their rapid response and highlighting the issue with permissions.
For interest, on using the /Documents folder, more options came up for sharing with other apps.
There is also a useful article on how app extensions work (host apps, app extensions and container apps) here:
https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionOverview.html
I have an iOS app which was running fine until yesterday and suddenly started to crash with Thread 1: signal SIGABRT at this point:
class AppDelegate: UIResponder, UIApplicationDelegate {
Having no idea of the cause I typed bt in the debugging console and got this:
(lldb) bt
* thread #1: tid = 0xda342, 0x0000000194637270 libsystem_kernel.dylib`__pthread_kill + 8, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x0000000194637270 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00000001946d5170 libsystem_pthread.dylib`pthread_kill + 112
frame #2: 0x00000001945aeb18 libsystem_c.dylib`abort + 112
frame #3: 0x000000018badf2ec GraphicsServices`_GSRegisterPurpleNamedPortInPrivateNamespace + 424
frame #4: 0x000000018bade1d4 GraphicsServices`_GSEventInitializeApp + 140
frame #5: 0x0000000186c86c38 UIKit`UIApplicationMain + 712
* frame #6: 0x00000001000592f0 TheApp`main + 164 at AppDelegate.swift:13
frame #7: 0x000000019451ea08 libdyld.dylib`start + 4
(lldb)
Browsing the net for similar issues I have read it may be due to some problems related to the StoryBoard, but since I am doing everything programmatically I have some doubts that it applies to my case. I have also tried to use an exception break point just in case, but with no success.
I have even remade the project, the problem is still there. It seems something goes wrong even before my code starts to execute. I wonder what I can check.
Anyway if someone can give me a hint on what may be the issue, or on how to further investigate, that would be much appreciated.
I had a working MKMapKit working in an app Im working on and decided to
convert it to MapQuest's MQMapKit which is supposed to be a drop-in replacement from
what I understand. After doing so (and checking for any 'MK' map stuff...which I dont
believe I have any now, they are all 'MQ' map references), Im getting the following
crash when the app tries to start up. Im not sure where 'prepareKeyForNewAnimation'
comes from. It seems to me to be a MapQuest Library issue (which is version 1.0.1).
Any ideas what is causing this or how to fix it? Thanks for any help on this!
013-05-28 07:01:23.394 myapp[25100:14003] === set USER center
2013-05-28 07:01:23.394 myapp[25100:14003] spanVal <0.300000>
2013-05-28 07:01:23.503 myapp[25100:14003] -[CALayer prepareKeyForNewAnimation:]: unrecognized selector sent to instance 0x85781e0
2013-05-28 07:01:23.504 myapp[25100:14003] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[CALayer prepareKeyForNewAnimation:]: unrecognized selector sent to instance 0x85781e0'
*** First throw call stack:
(0x1ec7012 0x1c3ae7e 0x1f524bd 0x1eb6bbc 0x1eb694e 0x55e9b 0x248053f 0x2492014 0x24827d5 0x1e6daf5 0x1e6cf44 0x1e6ce1b 0x2efe7e3 0x2efe668 0xb7effc 0x2042 0x1f75)
libc++abi.dylib: terminate called throwing an exception
backtrace:
* thread #1: tid = 0x1f03, 0x9bca39c6 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
frame #0: 0x9bca39c6 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x90065f78 libsystem_c.dylib`pthread_kill + 106
frame #2: 0x0250157b libsystem_sim_c.dylib`abort + 140
frame #3: 0x02413f7b libc++abi.dylib`abort_message + 105
frame #4: 0x02411a25 libc++abi.dylib`default_terminate() + 34
frame #5: 0x01c3b0c1 libobjc.A.dylib`_objc_terminate() + 94
frame #6: 0x02393652 libstdc++.6.0.9.dylib`std::terminate() + 21
frame #7: 0x01c3b039 libobjc.A.dylib`objc_terminate + 11
frame #8: 0x02492027 libdispatch.dylib`_dispatch_client_callout + 33
frame #9: 0x024827d5 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 296
frame #10: 0x01e6daf5 CoreFoundation`__CFRunLoopRun + 1925
frame #11: 0x01e6cf44 CoreFoundation`CFRunLoopRunSpecific + 276
frame #12: 0x01e6ce1b CoreFoundation`CFRunLoopRunInMode + 123
frame #13: 0x02efe7e3 GraphicsServices`GSEventRunModal + 88
frame #14: 0x02efe668 GraphicsServices`GSEventRun + 104
frame #15: 0x00b7effc UIKit`UIApplicationMain + 1211
frame #16: 0x00002042 myapp`main(argc=1, argv=0xbffff364) + 130 at main.m:16
frame #17: 0x00001f75 myapp`start + 53
[EDIT] Very bizarre. This was happening in the simulator on ipad. I tried plugging
in my iphone 5 and I got a provisioning error (even though it worked earlier and shouldnt
have been an issue. When I edited the dev profile and added a couple other users that
I had and re-downloaded it, it still didnt work. When I went into the settings and changed
the debug/release/distro settings to the generic 'Developer profile' for all three it
now worked fine without crashing. Bizarre!
[EDIT] NOT so solved....still crashing on and off, mostly on. Any help would be
appreciated.
[SOLVED] Found this article where I missed adding -ObjC to 'Other Linker Flags':
mapquest developer site
My App does not crash on my iDevices, but the apple review team says it is crashing on ipad 6.0.1. This is the relevant part of the resymbolicated log:
Last Exception Backtrace:
0 CoreFoundation 0x327fb29e __exceptionPreprocess + 158
1 libobjc.A.dylib 0x394dd97a objc_exception_throw + 26
2 UIKit 0x38897d54 +[UIStoryboard storyboardWithName:bundle:] + 436
3 UIKit 0x386da406 -[UIApplication _loadMainStoryboardFileNamed:bundle:] + 38
4 UIKit 0x38563794 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 524
5 UIKit 0x3850bc34 -[UIApplication handleEvent:withNewEvent:] + 1000
6 UIKit 0x3850b6c8 -[UIApplication sendEvent:] + 68
7 UIKit 0x3850b116 _UIApplicationHandleEvent + 6150
8 GraphicsServices 0x35c8759e _PurpleEventCallback + 586
9 CoreFoundation 0x327d067e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 10
10 CoreFoundation 0x327cfee4 __CFRunLoopDoSources0 + 208
11 CoreFoundation 0x327cecb2 __CFRunLoopRun + 642
12 CoreFoundation 0x32741eb8 0x32739000 + 36536
13 CoreFoundation 0x32741d44 CFRunLoopRunInMode + 100
14 UIKit 0x38562478 -[UIApplication _run] + 664
15 UIKit 0x3855f2f4 UIApplicationMain + 1116
16 MyApp 0x0007362e main (main.m:16)
17 MyApp 0x000735e4 start + 36
Does this mean that the Storyboard is the problem (line 2)?
To answer your question:
Does this mean that the Storyboard is the problem (line 2)?
It means that the most likely problem is related to the storyboard loading - either with the storyboard or the bundle - as that's where the exception is being thrown from. Without knowing the source code of UIStoryboard and what's on line 436 that makes it throw an exception, that's probably about as specific as you'll get from a non-Apple employee.
To get beyond that and actually reproduce the crash locally (so you can work toward fixing it):
Validate packaging / do a clean/fresh install (as suggested in the comments)
Try on a different device (perhaps there's something leftover that a clean isn't removing properly)
Try an older iOS version (maybe they're accidentally giving you incorrect information to the iOS version?)
Try simulating low memory environment while your app is in the background (maybe the crash is related to your app closing and restarting in the background in this situation?)
More likely you'll want to get more info from the review team than just a stack trace if you can't reproduce the issue:
Can you get more exact reproduction steps on how they are causing the crash?
Is this an update to an existing app? Might they have an old version of your app that hasn't been cleaned properly?
My guess is that at some point you changed the name of the storyboard file but did not reflect that change in Xcode under (project) > (target) > General > Deployment Info > Main Interface.
Consequently, it's still working on your device (because you still have the storyboard file with the old name installed on that device, as well as the new one), but it crashes when newly-installed on other devices, where only the storyboard file with the new name exists.
Using iOS 6.1 my App crashes regulary, directly after startup, when it attempts to make several HTTP-Requests, but it works fine on any OS < 6.1.
I'm experiencing
EXC_BAD_ACCESS crashes in the strlen function called from the Queue : com.apple.CFURLCACHE_work_queue, everytime my App is started, except for the first time.
I could resolve the issue by clearing the NSURLCache, directly after the app started:
[[NSURLCache sharedURLCache] removeAllCachedResponses];
Does anyone else experience these crashes? Could there be some issue in the application code causing these crashes? Or should this be a bug filed to apple?
Experiencing a similar crash since iOS 6.1 with a newly installed application. The difference is that the crash occurs when tapping a text cell in a table view. No web requests are being made at this time.
This is the bt:
thread #4: tid = 0x2903, 0x3ae7ad74 libsystem_c.dylib`strlen + 28, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x3ae7ad74 libsystem_c.dylib`strlen + 28
frame #1: 0x3ac6be24 libsqlite3.dylib`___lldb_unnamed_function282$$libsqlite3.dylib + 1232
frame #2: 0x3ac74a5e libsqlite3.dylib`sqlite3_file_control + 174
frame #3: 0x328493fe CFNetwork`__CFURLCache::RecreateEmptyPersistentStoreOnDiskAndOpen_NoLock() + 30
frame #4: 0x32849000 CFNetwork`__CFURLCache::RecreateEmptyPersistentStoreOnDiskAndOpen() + 44
frame #5: 0x327f9488 CFNetwork`__CFURLCache::OpenDatabase() + 192
frame #6: 0x32846a72 CFNetwork`__CFURLCache::ProcessCacheTasks0(bool) + 358
frame #7: 0x32846900 CFNetwork`__CFURLCache::ProcessCacheTasks(bool) + 36
frame #8: 0x3284681e CFNetwork`__CFURLCache::_CFURLCacheTimerCallback0() + 358
frame #9: 0x328466ac CFNetwork`__CFURLCache::_CFURLCacheTimerCallback(void*) + 32
frame #10: 0x328490fc CFNetwork`__SignalWorkerTaskToPerformWork_block_invoke_0 + 12
frame #11: 0x3ae4611e libdispatch.dylib`_dispatch_call_block_and_release + 10
frame #12: 0x3ae49ece libdispatch.dylib`_dispatch_queue_drain$VARIANT$mp + 142
frame #13: 0x3ae49dc0 libdispatch.dylib`_dispatch_queue_invoke$VARIANT$mp + 40
frame #14: 0x3ae4a91c libdispatch.dylib`_dispatch_root_queue_drain + 184
frame #15: 0x3ae4aac0 libdispatch.dylib`_dispatch_worker_thread2 + 84
frame #16: 0x3ae7aa10 libsystem_c.dylib`_pthread_wqthread + 360
frame #17: 0x3ae7a8a4 libsystem_c.dylib`start_wqthread + 8
Reported this as a TSI to Apple, it was reviewed and they requests that I log this as a bug, still need to do this.
Interestingly enough the solution which you found also helped me, clearing the cache at launch solved this problem.
This is only half an answer, but I'm running into a very similar problem whilst running my unit tests. Bizarrely, this only seemed to start happening today.
The full details of my issue are outlined in this Apple dev forums thread.
The common link between our problems appears to be the call to RecreateEmptyPersistentStoreOnDiskAndOpen_NoLock(). If my understanding of CFURLCache is correct, and based on the backtrace, it uses a sqlite3 database internally as a cache. I'd assume this function call creates the empty sqlite3 database on disk.
I was able to repeatedly and consistently stop my tests crashing by deleting the simulator's Library/Caches directory (~/Library/Application Support/iPhone Simulator/6.1/Library/Caches) and make the crash return by re-creating that directory.
Deleting the entire simulator home directory and letting it be recreated by launching my app in the simulator would also fix and re-create the issue.
I'm guessing this is an OS bug; the curious thing is why for me, it only just started happening.