[Swift] Calls to "po <# something #>" in the debugger cause a deadlock in String.init<T>(_ instance: T)
| Originator: | eliacereda | ||
| Number: | rdar://23875049 | Date Originated: | 13 December 2015 |
| Status: | Open | Resolved: | |
| Product: | Developer Tools | Product Version: | |
| Classification: | Deadlock | Reproducible: | Always |
Summary: After a call to "po <# something #>" in the debugger, subsequent calls to String.init<T>(_ instance: T) and related methods will deadlock. This seems to happen only on actual iOS devices (i.e. not the simulator). I've created a proof of concept and attached it to the bug report. The stack trace of the deadlock is also attached. Steps to Reproduce: Run the attached application, tap on the "Test deadlock" button. Expected Results: The call to "po" should not cause deadlocks. Actual Results: The application hangs. Pausing the debugger now will reveal that the process is stuck on a __psynch_mutexwait call inside String.init<T>(_ instance: T). If the breakpoint on nop() is disabled the program doesn't hang. Version: Xcode 7.2 (7C68) Notes: I'm filing a bug here instead of the opensource bug tracker because this bug only happens on iOS devices and I don't know of a way to reproduce it with opensource tools (unless there's a way to run the Swift REPL on device?) Configuration: Happens on iPhone 6 - iOS 9.0.2 (13A452) Doesn't happen on iPhone Simulator Attachments: 'StringInterpolationDeadlock.zip' (http://cl.ly/e4SI) and 'stacktrace.png' (http://cl.ly/e4TA) were successfully uploaded.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!