Hard crash in FolderItem.Child

Does anyone have an idea what might cause this lovely hard crash:

[quote]
Crashed Thread: 5

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler [10963]

Application Specific Information:
*** CFRetain() called with NULL ***

Thread 5 Crashed:
0 com.apple.CoreFoundation 0x00007fff377dfc4e CFRetain.cold.1 + 14
1 com.apple.CoreFoundation 0x00007fff37632459 CFRetain + 106
2 com.apple.CoreServicesInternal 0x00007fff501999db _CreateByResolvingAliasFile(__CFAllocator const*, __CFURL const*, unsigned long, unsigned char*, __CFError**) + 54
3 com.apple.CoreServicesInternal 0x00007fff50199801 _URLCreateByResolvingAliasFile + 48
4 com.apple.Foundation 0x00007fff39de80e6 -[NSURL(NSURL) initByResolvingAliasFileAtURL:options:error:] + 269
5 com.apple.Foundation 0x00007fff39de7fc9 +[NSURL(NSURL) URLByResolvingAliasFileAtURL:options:error:] + 61
6 com.xojo.XojoFramework 0x000000010ee5fc07 FolderItemImpNSURL::FolderItemImpNSURL(NSURL*, bool) + 81
7 com.xojo.XojoFramework 0x000000010ee61c15 FolderItemImpNSURL::GetChildByName(string, long) + 131
8 com.xojo.XojoFramework 0x000000010efc1e93 0x10edc5000 + 2084499
9 com.mothsoftware.mailarchiverx 0x000000010b44b488 FolderItem.Child%o%osb + 136
10 com.mothsoftware.mailarchiverx 0x000000010cc84057 reportPrinter.getFile%o%oosb + 695
11 com.mothsoftware.mailarchiverx 0x000000010cc8ad72 reportPrinter.getPDFFilePath%o%o + 8562
12 com.mothsoftware.mailarchiverx 0x000000010cc83294 reportPrinter.printTemplate%%o + 1668
13 com.mothsoftware.mailarchiverx 0x000000010c99a8f9 WriteMessageToPDF.Constructor%%osobbi8sss + 9225
14 com.mothsoftware.mailarchiverx 0x000000010c99602e WriteMessageToDatabase.Constructor%%osooss + 11102
15 com.mothsoftware.mailarchiverx 0x000000010c2bf7e8 MailParser.parse%i8%o + 17304
16 com.mothsoftware.mailarchiverx 0x000000010cd9c355 ArchiveThread.Archive%%o + 17685
17 com.mothsoftware.mailarchiverx 0x000000010cd931a5 ArchiveThread.Event_Run%%o + 117
18 com.xojo.XojoFramework 0x000000010f03c860 0x10edc5000 + 2586720
19 com.xojo.XojoFramework 0x000000010eef6345 0x10edc5000 + 1250117
20 libsystem_pthread.dylib 0x00007fff6ef5ae65 _pthread_start + 148
21 libsystem_pthread.dylib 0x00007fff6ef5683b thread_start + 15[/quote]

I’m trying to make a unique filename before writing a pdf:

[code]dim theFolderitem as folderitem
dim theFileNo as Integer

if parentFolderItem = nil then
'nothing to do
elseif not doFolder or PDFStructure = “all” then
theFolderitem = parentFolderItem.child(theName + “.pdf”)
while theFolderitem <> nil and theFolderitem.exists
theFileNo = theFileNo + 1
theFolderitem = parentFolderItem.child(theName + " " + str(theFileNo) + “.pdf”)
wend

ElseIf doFolder then
theFolderitem = parentFolderItem.child(theName)
while theFolderitem <> nil and theFolderitem.exists
theFileNo = theFileNo + 1
theFolderitem = parentFolderItem.child(theName + " " + str(theFileNo))
wend
end if[/code]

Using Xojo 2019r3, the user has 10.15.3.

Looks to me like a bug in macOS 10.15.3. It’s trying to call retain on an item that doesn’t exist, which it’s getting from trying to resolve an alias.

At least that’s my understanding of the crash report, consider yourself lucky you got this. If it was an NSException, you’d not get anything, just that your application silently fails.

You can avoid this by
Using folderitem.trueChild instead of folderitem.child to get the file within the folder, with out trying to automagically resolve the Alias.

Yup. Looks like another bug in the wonderful Crapolina. I’ll try the TrueChild.

Using .TrueChild didn’t make a difference.

when in the fog I try testing also other booleans like .isreadable etc.

[quote=480282:@Beatrix Willius]5 com.apple.Foundation 0x00007fff39de7fc9 +[NSURL(NSURL) URLByResolvingAliasFileAtURL:options:error:] + 61
6 com.xojo.XojoFramework 0x000000010ee5fc07 FolderItemImpNSURL::FolderItemImpNSURL(NSURL*, bool) + 81
7 com.xojo.XojoFramework 0x000000010ee61c15 FolderItemImpNSURL::GetChildByName(string, long) + 131
8 com.xojo.XojoFramework 0x000000010efc1e93 0x10edc5000 + 2084499
9 com.mothsoftware.mailarchiverx 0x000000010b44b488 FolderItem.Child%o%osb + 136[/quote]

stack frame 9 id your code where you call child with a name
8 down to 6 are in the framework trying to resovle the folderitem to an existing one and then things go off the rails
makes me wonder if the bug is in the framework trying to resolves this using the wrong call or passing a bad param to the OS API which is what causes the OS API to go fubar

parentFolderItem isn’t nil when resolving an alias so your

if parentFolderItem = nil then

check is basically mute allowing the code to carry on to a check for a file inside a non-existent folder which ultimately blows up.

Change

if parentFolderItem = nil then

to

if parentFolderItem = Nil or not parentFolderItem.Exists then

the nil check will happen before the OR so you’ll never get a failure after the OR if parentFolderItem hasn’t been initialised

should still get a NOE or something other than the app crashing hard even if parent folderitem exists is FALSE
but we can test your theory about whats broken if the code is altered to by adding a check for exists = false along the way

something like

dim theFolderitem as folderitem
dim theFileNo as Integer

if parentFolderItem = nil then
  'nothing to do
elseif parentFolderItem.exists = false then
   break /// <<<<<<<<<< this might be a problem
elseif not doFolder or PDFStructure = "all" then
  theFolderitem = parentFolderItem.child(theName + ".pdf")
  while theFolderitem <> nil and theFolderitem.exists
    theFileNo = theFileNo + 1
    theFolderitem = parentFolderItem.child(theName + " " + str(theFileNo) + ".pdf")
  wend
  
ElseIf doFolder then
  theFolderitem = parentFolderItem.child(theName)
  while theFolderitem <> nil and theFolderitem.exists
    theFileNo = theFileNo + 1
    theFolderitem = parentFolderItem.child(theName + " " + str(theFileNo))
  wend
end if

I’ve tested it all already and reproduced the crash, here’s the code if you want to put a ticket in, just create a folder called tt on your desktop, create an alias of it, trash tt, empty trash then run the code:

[code]dim theFolderItem As FolderItem
dim theFileNo As Integer
dim theName As String = “Moo”

dim parentFolderItem As FolderItem = SpecialFolder.Desktop.Child(“tt alias”)

if parentFolderItem = Nil or not parentFolderItem.Exists then //remove the or to see the crash
break // doesn’t stop here
end if

theFolderItem = parentFolderItem.child(theName + “.pdf”) // breaks here due to parentFolderItem failing
while theFolderItem <> nil and theFolderItem.Exists
theFileNo = theFileNo + 1
theFolderitem = parentFolderItem.child(theName + " " + str(theFileNo) + “.pdf”)
wend

break[/code]

oh nifty !
yeah this really needs a bug report
in 2019r1.1 it does stop on the break statement and theFolderitem is set to NIL
no crash

Thanks, guys, for trying to help. Unfortunately, there is no alias to resolve.

I’ve also removed all error handling and parent folder checking from the posted code. The folders reflect the mailbox structure from the users mailboxes and are created fine.

Today I’ll make the user another test version to see which filename is making the crash.

Feedback report: feedback://showreport?report_id=59530

The crash is quite different to what I posted above:

[quote]Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 XojoFramework 0x000000010689bdfb std::__1::pair<std::__1::__tree_iterator<std::__1::__value_type<RuntimeObject*, RuntimeObject**>, std::__1::__tree_node<std::__1::__value_type<RuntimeObject*, RuntimeObject**>, void*>, long>, std::__1::__tree_iterator<std::__1::__value_type<RuntimeObject, RuntimeObject**>, std::__1::__tree_node<std::__1::__value_type<RuntimeObject*, RuntimeObject**>, void*>, long> > std::__1::__tree<std::__1::__value_type<RuntimeObject, RuntimeObject**>, std::__1::__map_value_compare<RuntimeObject*, std::__1::__value_type<RuntimeObject*, RuntimeObject**>, std::__1::less<RuntimeObject*>, true>, std::__1::allocator<std::__1::__value_type<RuntimeObject*, RuntimeObject**> > >::__equal_range_multi<RuntimeObject*>(RuntimeObject* const&) + 41
1 XojoFramework 0x000000010689af65 RuntimeUnlockObject + 695
2 XojoFramework 0x00000001067cf2df std::__1::__vector_base<RBObject<RuntimeObject*>, std::__1::allocator<RBObject<RuntimeObject*> > >::~__vector_base() + 49
3 libsystem_c.dylib 0x00007fff69c2113c __cxa_finalize_ranges + 319
4 libsystem_c.dylib 0x00007fff69c21412 exit + 55
5 libdyld.dylib 0x00007fff69b77cd0 start + 8[/quote]

[quote]in 2019r1.1 it does stop on the break statement and theFolderitem is set to NIL
no crash[/quote]
Confirming that 2019r.1.1 does stop. But 2019r2.1 crashes…

What about Xojo 2019r3.1 ?

I don’t have 2019r3.1, but @Beatrix Willius in her post speaks of Xojo 2019r3.

[quote=480437:@Beatrix Willius]Feedback report: feedback://showreport?report_id=59530

The crash is quite different to what I posted above:[/quote]

Interesting, I get a different error, almost similar line for line to the one in your original post.

I hope it helps you in some way to get to the bottom of it.

@Carlo Rubini : yes, I’m still using 2019r3. Didn’t see any need to update to 2019r3.1.

@JulianS : that’s really odd. Was this on Catalina?

Yes, same on 10.15 and 10.15.4 (vms)