Mavericks crash

I have a function but on Mavericks, it crashes the app on the .Parent call. This is when it’s looking on a CD with perhaps some hidden folders/files involved,

0 libsystem_c.dylib 0x90a4a785 strlcpy + 53
1 com.apple.CoreServices.CarbonCore 0x976d8901 UTF8ToFSSpecName + 50
2 com.apple.CoreServices.CarbonCore 0x9767706d FSRefCreate + 423
3 com.apple.CoreServices.CarbonCore 0x97677510 PBGetCatalogInfoSync + 1025
4 com.apple.CoreServices.CarbonCore 0x97677107 FSGetCatalogInfo + 53
5 rbframework.dylib 0x0155f75d FolderItemImpMac2::FolderItemImpMac2(FSRef const&) + 189
6 rbframework.dylib 0x01560a96 FolderItemImpMac2::GetParent() + 62
7 rbframework.dylib 0x015bb98f folderParentGetter + 33
8 com.chickensys.translator6 0x000cb0d5 FolderItem.Parent.Get%o%oi4 + 85
9 com.chickensys.translator6 0x0087ff85 basEmuX.$POSIXPathRCS%s%o + 894

Here’s the code. Please never mind about an easier way to do this particular thing - the concern I have is that the REAL function .Parent crashes the whole app. This is with REAL2011r3 - and I know that the bug can’t be fixed, but I am looking for a way to work around it. I’m confident FolderItem.Parent works fine generally, this is probably just regarding the the hidden object/CD situation. Still, the REAL function in rbframework.dylib looks vulnerable.

This particular instance is particularly important because it has to do with my authorization routine for all my apps I sell.

[code]Function POSIXPathRCS(extends f as FolderItem) As String
Dim Msg As String
Dim EmptyStrCtr As Integer

Dim ThisName As String
Dim f2 As FolderItem

If f = Nil Then
  return ""
Else
  
  f2 = f
  Do
    ThisName = ReplaceStringAll(f2.Name, "/", ":")

    // checks bad volumes
    If ThisName = "" Then
      EmptyStrCtr = EmptyStrCtr + 1
      If EmptyStrCtr > 4 Then
        Msg = "/Volumes" + Msg
        Exit Do
      End If
    End If
    
    Msg = "/" + ThisName + Msg
    f2 = f2.Parent
    
    // means the root
    if f2 = Nil then
      Msg = "/Volumes" + Msg
      Exit Do
    End If
    
  Loop
  
  return Msg
 
End If

exception err

WriteExceptionLog(err, CurrentMethodName)

return Msg

End Function
[/code]

I’ve narrowed this down to two things: calling AbsolutePath on certain file objects, and calling Parent.

The “certain file objects” seem to be related to hidden files - not files starting with dots, but ones who attribute really is hidden. What I’m working with is a folder structure like this:

Folder 1 (hidden, made hidden with Toast 9)
Folder 2
Folder 3
Folder 4

Let’s say I go f = vol.Child(“Folder 1”)y, then f = f.Child(“Folder 2”), all okay. But if I then do Path = f.AbsolutePath, it bombs (on Mavericks). (Also, AbsolutePath blows up on anything under Folder 1.) Just as well, Parent blows up whenever I call it on an folder BELOW Folder 1.

The conclusion I draw is that objects within a hidden folder can’t use the AbsolutePath or Parent functions in Mavericks.

You may want to try the free version of Xojo, absolutePath is no more and is replaced with Native path which seems to give a POSIX Path under Cocoa.

No, no. I have Xojo and the problem exists there too. That’s too easy. Besides, I’m not going to let silly bugs stop me from supporting older OS’s and older Mac’s.

What I’m currently thinking on this one, is if it’s a Xojo bug or if it’s a Mavericks bug. The crash actually occurs in Apple’s function. If I know it’s a Apple bug, then I’m not too stressed about it, but I’d like to relay it to Apple so they get it fixed.

This is a rare bug, because usually nobody accesses hidden folder contents. The only reason I am is that I use it as part of my authorization scheme and part of it relies on grabbing a file within hidden areas (don’t want people mimicing the copy-protection routines/schemes). So if I know Apple will get this fixed, I can give a better answer to my users whom all of a sudden can’t authorize my software.

Oh - I should mention that NativePath and ShellPath work. It’s just AbsolutePath and Parent (which is a little strange because it’s not a string type of function).

And to be a little more specific, fixing the bug myself or working around it is just a half-solution. The bug affects people who get my CD, install an older version of the program off the CD, and then run it to authorize it. (THEN they are prompted to update it.) So my best scenario is one where that CD version is still valid; so, if it’s a Apple bug (which I feel it is), I tell users it’s an Apple problem, give them a workaround but assure them their CD is still valid for other installs. Then when Apple fixes it, no more worrying about it.

[quote=42992:@Garth Hjelte]Oh - I should mention that NativePath and ShellPath work. It’s just AbsolutePath and Parent (which is a little strange because it’s not a string type of function).

And to be a little more specific, fixing the bug myself or working around it is just a half-solution. The bug affects people who get my CD, install an older version of the program off the CD, and then run it to authorize it. (THEN they are prompted to update it.) So my best scenario is one where that CD version is still valid; so, if it’s a Apple bug (which I feel it is), I tell users it’s an Apple problem, give them a workaround but assure them their CD is still valid for other installs. Then when Apple fixes it, no more worrying about it.[/quote]

Assuming Apple fixes it which I doubt they will.
If you look a frame 5
5 rbframework.dylib 0x0155f75d FolderItemImpMac2::FolderItemImpMac2(FSRef const&) + 189
That’s a call in the framework using an FSRef which is deprecated
If you report this to Apple they’ll likely say “it’s Xojo bug as they are using deprecated API’s” which is true.

Have you tried your code in Xojo ?
If so & it works then its likely a bug from an older framework running on a newer OS.
There the answer may well be “Update as its fixed in a later version”

And since you DO report “that NativePath and ShellPath work.” the answer seems to be “update” and use those.
And maybe a recompile with an older version to support older versions of OS X

This is definitely my recommendation too. FolderItem got a lot of love since 2011.

See the earlier post where I said it does it on Xojo too.

See above where I mention that since Parent doesn’t work, the issue doesn’t totally rest on the "Path’ type of functions.

And see the Feedback report <https://xojo.com/issue/30453>. Here’s the crash log from Xojo r3.1 - you are still using FSRef. It’s the same lines, everything is the same. I made a test app using Xojo, that’s how I diagnosed all of this out.

So, are you saying in essence is that Xojo isn’t Maverick-ready? I know my issue is in an area rarely dealt with - parsing inside hidden folders - but you are still using deprecated FSRef and associated functions in the latest Xojo.

Since that’s the case, shouldn’t it be public knowledge that even the latest Xojo can’t compile 10.9 apps that are truly compliant?

It looks like FolderItem needs more love (using CFURL or NSURL) to be 10.9 - or even 10.8, since FSRef was deprecated then - compliant.


Process: Mav File Test.debug [387]
Path: /Users/USER/Desktop/Mav File Test.debug.app/Contents/MacOS/Mav File Test.debug
Identifier: com.chickensys.mavfiletest
Version: ??? (1.0.0.0.0)
Code Type: X86 (Native)
Parent Process: launchd [155]
Responsible: Mav File Test.debug [387]
User ID: 501

Date/Time: 2013-10-29 12:56:17.299 -0500
OS Version: Mac OS X 10.9 (13A603)
Report Version: 11
Anonymous UUID: 055D4526-4975-4571-42E8-AF1E10E33033

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000

VM Regions Near 0:
→ __PAGEZERO 0000000000000000-0000000000001000 [ 4K] —/— SM=NUL /Users/USER/Desktop/Mav File Test.debug.app/Contents/MacOS/Mav File Test.debug
__TEXT 0000000000001000-0000000000193000 [ 1608K] r-x/rwx SM=COW /Users/USER/Desktop/Mav File Test.debug.app/Contents/MacOS/Mav File Test.debug

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_c.dylib 0x92fb4785 strlcpy + 53
1 com.apple.CoreServices.CarbonCore 0x9b68b901 UTF8ToFSSpecName + 50
2 com.apple.CoreServices.CarbonCore 0x9b62a06d FSRefCreate + 423
3 com.apple.CoreServices.CarbonCore 0x9b62a510 PBGetCatalogInfoSync + 1025
4 com.apple.CoreServices.CarbonCore 0x9b62a107 FSGetCatalogInfo + 53
5 rbframework.dylib 0x0023c692 0x1e2000 + 370322
6 rbframework.dylib 0x002408f5 0x1e2000 + 387317
7 rbframework.dylib 0x002749df folderParentGetter + 31

A long while ago I found a problem with accessing folderitem.item(index). See <https://xojo.com/issue/21205>. Because Xojo didn’t deem the bug important to fix and I exchanged the Xojo call with something from Charles Yeomans. Perhaps that module contains also code for your problem. The project is called “REALbasicStandardLibrary”.

And my Feedback issue is now obsolete because the problem was only for Snow Leopard. Sigh…

Thanks Bea - that’s not it but it is somewhat related. This only has to do with Mavericks.

In the Xojo build, are you compiling for Cocoa?

2 com.apple.CoreServices.CarbonCore	0x9b62a06d FSRefCreate + 423

Also you could try replacing AbsolutePath and Parent with your own functions using extends.

There’s really no practical replacement for Parent, there’s really no other way to do it, unless you really go off the grid and use Declares, kludging lots of NSURL or other information out of the FolderItem, working with it, then creating a FolderItem from that.

This would be a job for MBS really.

I’ve been off-list with Joe and Norman - the problem isn’t with hidden folders (my fault), it’s with parsing Mac OS Standard (I assume that’s HFS, not HFS+) volumes. Try it - in Mavericks, pull out an older Mac-formatted CD, parse down with Child(), then try to parse up with Parent. Parent will fail. (You can try a image as well, but only in Leopard and prior can you create a Mac OS Standard image.)

This is a current issue with Xojo.

Xojo still uses the FSRef stuff that was deprecated in 10.8, it looks like they haven’t switched over to the proper NSURL or CFURL things yet in the FolderItems.

So I’d like to find out if Apple may fix it and the issue will go away, or Xojo can workaround it in a new version. Personally for me, I hope it’s a Mavericks issue because I don’t want to be forced to use the latest Xojo (since it can’t write UB’s).

You could just parse .ShellPath or your custom .AbsolutePath replacement to verify your place in the path, then match the parent segment, and return it.

In Carbon or Cocoa? Would make sense for Carbon since they haven’t really worked on that framework at all.

They use FSRef in the Cocoa builds too. (You can tell by my crash logs.)

Good idea for Parent. Though… I’ll never forget many, many years ago totally being mouthed out (appropriately) by Joe Strout to not, not, not, not use paths, use Child() and Parent(). Yet paths live on.

I’m looking for a response to “why does AbsolutePath and Parent crash in Mavericks upon working on a Mac OS Standard volume?” I’d like to know if it’s a Apple Mavericks bug or a Xojo one.

Could you upload a disk image in that format? As you’ve noted, 10.7-10.9 don’t generate HFS standard volumes.

Uploaded on the Feedback entry, thanks for looking at this.