App crashing when using PString type in declares, and workaround

I got a crash report from my only user running the 10.10.3 beta for whom I had built my app with Xojo 2015r1.

Is this a known issue, and is a fix likely to come from Apple, or is this rather an issue in Xojo?

Oddly, many users run the app built with 2013r3 on the OSX beta without such issues, it appears.


[code]Process: Find Any File [2949]
Path: /Applications/Find Any Any File
Identifier: org.tempel.findanyfile
Version: 1.8.9 (
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: Find Any File [2949]
User ID: 501

Date/Time: 2015-03-22 12:07:53.736 -0400
OS Version: Mac OS X 10.10.3 (14D105g)
Report Version: 11
Anonymous UUID: CA4D2A64-B9AA-8A67-07CB-EF1659FFA852

Time Awake Since Boot: 78000 seconds

Crashed Thread: 0 Dispatch queue:

Exception Codes: KERN_INVALID_ADDRESS at 0x00000000e800a723

VM Regions Near 0xe800a723:
Stack 00000000bf800000-00000000c0000000 [ 8192K] rw-/rwx SM=COW
Submap 00000000ffff0000-00000000ffff1000 [ 4K] r–/r-- SM=PRV process-only VM submap

Application Specific Information:
Performing @selector(_close:) from sender _NSThemeCloseWidget 0x1dd5940

Thread 0 Crashed:: Dispatch queue:
0 ??? 0xe800a723 0 + 3892356899
1 com.xojo.XojoFramework 0x00a74a39 PermissionsInitializer + 37949
2 com.xojo.XojoFramework 0x00a74a6e PermissionsInitializer + 38002
3 com.xojo.XojoFramework 0x00a6c7a1 PermissionsInitializer + 4517
4 com.xojo.XojoFramework 0x00ad724e StyledTextPrinterWidthGetter + 2962
5 com.xojo.XojoFramework 0x00ad724e StyledTextPrinterWidthGetter + 2962
6 com.xojo.XojoFramework 0x00a049f7 EmbedWithinInternal + 10873
7 com.xojo.XojoFramework 0x00a04aa9 EmbedWithinInternal + 11051
8 com.xojo.XojoFramework 0x009a6910 Introspection_GenericSetter + 21317
9 0x903aefaa __19-[NSWindow __close]_block_invoke + 153
10 0x903aef09 -[NSWindow __close] + 376
11 0x903aec4e -[NSWindow _close:] + 173
12 libobjc.A.dylib 0x92a93853 -[NSObject performSelector:withObject:] + 70
13 0x9027a4de __36-[NSApplication sendAction:to:from:]_block_invoke + 51
14 libsystem_trace.dylib 0x9a3b5c03 _os_activity_initiate + 89
15 0x9027a3f7 -[NSApplication sendAction:to:from:] + 602
16 0x90291c56 -[NSControl sendAction:to:] + 102
17 0x90291b3b __26-[NSCell _sendActionFrom:]_block_invoke + 176
18 libsystem_trace.dylib 0x9a3b5c03 _os_activity_initiate + 89
19 0x90291a6a -[NSCell _sendActionFrom:] + 161
20 0x90537ec6 __48-[NSCell trackMouse:inRect:ofView:untilMouseUp:]_block_invoke989 + 43
21 libsystem_trace.dylib 0x9a3b5c03 _os_activity_initiate + 89
22 0x9028fd5e -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 2908
23 0x902ec2ec -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 833
24 0x9028e32c -[NSControl mouseDown:] + 762
25 0x90379f62 -[_NSThemeWidget mouseDown:] + 378
26 0x90895486 -[NSWindow _reallySendEvent:isDelayedEvent:] + 13689
27 0x90178d6a -[NSWindow sendEvent:] + 526
28 com.xojo.XojoFramework 0x0099adce TextOutputStream_Create + 23099
29 0x90175354 -[NSApplication sendEvent:] + 4765
30 com.xojo.XojoFramework 0x0098a5c9 ParseJSON + 12347
31 com.xojo.XojoFramework 0x0098a60a ParseJSON + 12412
32 org.tempel.findanyfile 0x0000bc8a Delegate.Invoke%% + 34
33 org.tempel.findanyfile 0x0008474e Application._CallFunctionWithExceptionHandling%%op + 248
34 com.xojo.XojoFramework 0x00ab123a SSLSettings_SetValidateCertificates + 1002
35 com.xojo.XojoFramework 0x0098a538 ParseJSON + 12202
36 0x9009566c -[NSApplication run] + 1003
37 com.xojo.XojoFramework 0x00ab12b7 SSLSettings_SetValidateCertificates + 1127
38 com.xojo.XojoFramework 0x00aaf84c RuntimeRun + 49
39 org.tempel.findanyfile 0x00153e0c REALbasic._RuntimeRun + 34
40 org.tempel.findanyfile 0x00007930 _Main + 257
41 org.tempel.findanyfile 0x000027b8 main + 36
42 org.tempel.findanyfile 0x0078b27d start + 53[/code]

[quote=175763:@Thomas Tempelmann]I got a crash report from my only user running the 10.10.3 beta for whom I had built my app with Xojo 2015r1.

Is this a known issue, and is a fix likely to come from Apple, or is this rather an issue in Xojo?[/quote]

Could you post the full crash log somewhere?

I’ve seen this one before, it was a NSScrollView on the window that caused it, are you using a NSScrollView?

I’ve uploaded this and some more related reports here:

Oddly, they’re all different.

It appears it has to do with showing a contextual popup menu.

Sam, I am not using an NSScrollView explicitly. Maybe it’s part of a large popup menu, though?

I’ll see that I get the OSX beta installed later today to see if I can reproduce it.

The offending app is here, BTW:

The user just informed me that the crash does not occur with the same app (FAF 1.8.9), but built with Xojo 2013r3.3

I haven’t been following the other thread on this, but it seems like something Apple broke and will fix before release.

This is unrelated to the other thread.

In fact (I only now got to testing this myself), it’s not even related to 10.10.3! It’s happening on 10.10.2 and 10.9 as well. It appears to be a regression in Xoxjo 2015 or 2014.

I’ll do some more testing to pinpoint the version, if that helps.

Get them to try with the latest update (I installed it today on my 10.10.3 test machine, and the two apps that were crashing on launch, now work).

Turns out this is an issue introduced in Xojo 2014r3 apparently related to using Dynamic String Constants.

I’ve filed a bug report with a demo project: <>

Bug got confirmed and fixed.

Everyone beware: Looks like using Dynamic String Constants from Xojo 2014r3 up to 2015r1 is buggy to the point of getting crashes on OS X. Let’s wait for 2015r2 where this is hopefully fixed again, then.

Dynamic string constants aren’t the problem. The only thing that this bug affected is the conversion of Strings to PStrings.

In this case the Pstrings were for calling Carbon Menu Manager API’s

How did you figure out it was Dynamic Constants? I had a series of crashes last year, that produced reports similar. However I found that altering the way I use NSScrollView solved them.

Does that mean that if I search the project for uses of “PString” and replace all of them with code that avoids this type, e.g. by using MemoryBlocks, I am able to work around this bug?

I cannot say for sure, but I am using dynamic string constants in OS X and iOS together with the current release and there’s no problems. Would be worth giving it a try in your project.

Ulrich, didn’t you see the reply from Joe where he clarified that this bug is not related to dynamic string constants?

Yes, sure, sorry for being unclear. This was just meant to encourage you to give removing PStrings a try and to assure Sam it is NOT dynamic constants.

I just did that: Found all uses of the PString type (!) in my code, which only occured in declare statements, replaced them to take the Ptr type instead, and changed calls like this:

SetMenuTitle (n, title)


dim title2 as new MemoryBlock (title2.LenB+1) title2.PString(0) = title SetMenuTitle (n, title2)

And that seems to be working when built with 2015r1

It saddens me, though, that I could not get this critical information for implementing a work-around without making public wrong assumptions here and waiting to get corrected.

You could use the modern replacement functions for those taking PStrings, which were deprecated in 10.5. In this case, SetMenuTitleWithCFString.