jingham@apple.com (JIRA User), who's the right person to look at this?

Comment by Jim Ingham (JIRA)

If you put the same code (plus "import Foundation") in a .swift file, compile and run it you get:

2018-09-05 09:51:36.277 doesitcrash[23667:9587705] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSDataDetector enumerateMatchesInString:options:range:usingBlock:]: Range or index out of bounds'

*

**

• • • First throw call stack:

(

0 CoreFoundation 0x00007fff2c4342db __exceptionPreprocess + 171

1 libobjc.A.dylib 0x00007fff535e0c76 objc_exception_throw + 48

2 CoreFoundation 0x00007fff2c4c5d7d +[NSException raise:format:] + 205

3 Foundation 0x00007fff2e5235c3 -[NSDataDetector enumerateMatchesInString:options:range:usingBlock:] + 440

4 doesitcrash 0x00000001067b73bb main + 1035

5 libdyld.dylib 0x00007fff541fa015 start + 1

)

libc++abi.dylib: terminating with uncaught exception of type NSException

Abort

I don't know enough about the NSRange & NSRangeDetectors to see if this a bug in the code snippet, or in Foundation.

Comment by Jim Ingham (JIRA)

I removed lldb from the component since this clearly isn't an lldb bug. Not sure what the right component is, however.

No, no. This bug is about not printing 'The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.' when a playground fails, because that's not an option. It's not about the actual mistake in the code (which is user error).

Comment by Jim Ingham (JIRA)

Ah, I see.

The playground runner tells lldb to run an expression, the expression crashes, and this is the string we return when an expression crashes and we've been told not to unwind. Note, the expression evaluation also returns a status which the runner can use to tell directly that the expression crashed.

This isn't a bug in any of the tools covered here. We have no way of knowing that the playground expression isn't being run interactively, and even if we did we don't know what message the runner might want to see. So I don't think it's worthwhile to change the message lldb prints. It's really up to the runner to print what it thinks is useful information from this event. For instance they could use Kuba's new frame detectors to print the ObjC exception message when we stop at an ObjC exception...

This bug really needs to get filed on Xcode.