removeItemAtPath:error: crashing

Scripting Forums AppleScriptObjC and Xcode
#1

Has anyone experienced a crash calling the method removeItemAtPath_error_ with Xcode 4.6?
Here the simple code lines


        --  dst is the file path to the file to remove
	set localFileManager to (current application's NSFileManager's defaultManager())
        set {theresult, theError} to  localFileManager's removeItemAtPath_error_(dst, reference)

the following code does work.
After the first crash it keeps crashing until a thorough clean of the product.


        --  dst is the file path to the file to remove
	set localFileManager to (current application's NSFileManager's defaultManager())
        set {theresult, theError} to  localFileManager's removeItemAtPath_error_(dst, missing value)

Model: macbook Pro
Browser: Safari 536.25
Operating System: Mac OS X (10.8)

#2

FWIW, it’s working as expected here…

#3

Without garbage collection?
Under 10.8.xx.
With and without ARC?
In my environement it keeps crashing if i use the reference for the error parameter.

#4

I only tested it with garbage collection – now I see what you mean. I suggest you log a bug report ASAP…

#5

Hang on, I tried again with a new project, and it’s working fine, with or without ARC (although you probably should always use ARC if not using garbage collection). Does it log theError OK?

#6

Hi Shane,

I started a new project with the following code:


script AppDelegate
	property parent : class "NSObject"
	
	on applicationWillFinishLaunching_(aNotification)
		-- Insert code here to initialize your application before any files are opened 
	end applicationWillFinishLaunching_
	
	on applicationShouldTerminate_(sender)
		-- Insert code here to do any housekeeping before your application quits 
		return current application's NSTerminateNow
	end applicationShouldTerminate_
	
	on testRemoveAtPath_(sender)
		set overwiteItem to true
		set src to "/Users/kader/Desktop/Test Hotfolder/OUT/TESTCOPY.JPG"
		set dst to "/Users/kader/Desktop/Test Hotfolder/OUT/TESTCOPY2.JPG"
		
		set localFileManager to (current application's NSFileManager's defaultManager())
		
		set itemExists to localFileManager's fileExistsAtPath_(dst)
		if  itemExists as boolean
			if overwiteItem
				set theresult to  localFileManager's removeItemAtPath_error_(dst, reference)
				log theresult

                                set theresult to localFileManager's copyItemAtPath_toPath_error_(src, dst, reference)
				log theresult
			else
				-- leave as is
				log "leave as is"
			end
		else
			-- copy file to dst
			log "copy file"
			set theresult to localFileManager's copyItemAtPath_toPath_error_(src, dst, reference)
			log theresult
		end
	end
end script

I now suspect that the copyItemAtPath_toPath_error_ method is the problem.
If I comment these lines out then the code runs OK otherwise it crashes.

Here is the crash log :


CoreFoundation`CFRetain:
0x7fff904ea080:  pushq  %rbp
0x7fff904ea081:  movq   %rsp, %rbp
0x7fff904ea084:  pushq  %rbx
0x7fff904ea085:  pushq  %rax
0x7fff904ea086:  movq   %rdi, %rbx
0x7fff904ea089:  testq  %rbx, %rbx
0x7fff904ea08c:  jne    0x7fff904ea0ae            ; CFRetain + 46
0x7fff904ea08e:  leaq   1620375(%rip), %rax       ; "*** CFRetain() called with NULL ***"
0x7fff904ea095:  movq   %rax, 2285484(%rip)       ; kd_block_encoder::encode(kdu_block*, bool, double, unsigned short) + 5612
0x7fff904ea09c:  int3   
0x7fff904ea09d:  callq  0x7fff90663930            ; symbol stub for: getpid
0x7fff904ea0a2:  movl   %eax, %edi
0x7fff904ea0a4:  movl   $9, %esi
0x7fff904ea0a9:  callq  0x7fff90663984            ; symbol stub for: kill
0x7fff904ea0ae:  testb  $1, %bl
0x7fff904ea0b1:  jne    0x7fff904ea101            ; CFRetain + 129
0x7fff904ea0b3:  movl   8(%rbx), %eax
0x7fff904ea0b6:  shrl   $8, %eax
0x7fff904ea0b9:  andl   $1023, %eax
0x7fff904ea0be:  movq   (%rbx), %rcx
0x7fff904ea0c1:  testq  %rcx, %rcx
0x7fff904ea0c4:  je     0x7fff904ea124            ; CFRetain + 164
0x7fff904ea0c6:  cmpq   2309995(%rip), %rcx       ; kd_create_dwt_description(int, int, kdu_params*, int, bool&, bool&, bool&, int&, kdu_kernel_step_info*&, float*&) + 1399
0x7fff904ea0cd:  je     0x7fff904ea124            ; CFRetain + 164
0x7fff904ea0cf:  leaq   2301786(%rip), %rdx       ; kd_block::retrieve_data(kdu_block*, int) + 542
0x7fff904ea0d6:  cmpq   (%rdx,%rax,8), %rcx
0x7fff904ea0da:  je     0x7fff904ea124            ; CFRetain + 164
0x7fff904ea0dc:  movq   2309965(%rip), %rax       ; kd_create_dwt_description(int, int, kdu_params*, int, bool&, bool&, bool&, int&, kdu_kernel_step_info*&, float*&) + 1391
0x7fff904ea0e3:  testq  %rax, %rax
0x7fff904ea0e6:  je     0x7fff904ea10b            ; CFRetain + 139
0x7fff904ea0e8:  movq   %rbx, %rdi
0x7fff904ea0eb:  callq  *%rax
0x7fff904ea0ed:  cmpb   $1, %al
0x7fff904ea0ef:  jne    0x7fff904ea10b            ; CFRetain + 139
0x7fff904ea0f1:  callq  0x7fff90663438            ; symbol stub for: objc_collectableZone
0x7fff904ea0f6:  movq   %rax, %rdi
0x7fff904ea0f9:  movq   %rbx, %rsi
0x7fff904ea0fc:  callq  0x7fff90662f76            ; symbol stub for: auto_zone_retain
0x7fff904ea101:  movq   %rbx, %rax
0x7fff904ea104:  addq   $8, %rsp
0x7fff904ea108:  popq   %rbx
0x7fff904ea109:  popq   %rbp
0x7fff904ea10a:  ret    
0x7fff904ea10b:  movq   2086174(%rip), %rax       ; Librarian.__TEXT.__eh_frame + 9744
0x7fff904ea112:  leaq   2086167(%rip), %rsi       ; Librarian.__TEXT.__eh_frame + 9744
0x7fff904ea119:  movq   %rbx, %rdi
0x7fff904ea11c:  addq   $8, %rsp
0x7fff904ea120:  popq   %rbx
0x7fff904ea121:  popq   %rbp
0x7fff904ea122:  jmpq   *%rax
0x7fff904ea124:  movq   %rbx, %rdi
0x7fff904ea127:  xorl   %esi, %esi
0x7fff904ea129:  addq   $8, %rsp
0x7fff904ea12d:  popq   %rbx
0x7fff904ea12e:  popq   %rbp
0x7fff904ea12f:  jmpq   0x7fff904ea140            ; _CFRetain
0x7fff904ea134:  nopw   %cs:(%rax,%rax)

I hope you can find something useful.
Thanks for the efforts.

Model: macbook Pro
Browser: Safari 536.25
Operating System: Mac OS X (10.8)

#7

Was that with or without ARC?

#8

Hi Shane,

This is the case in both situations.
I also remarked that the return result differs between runs:
(
1,
“”
)

or

(
1,
“<Protocol: 0x7fff76558208>”
)

#9

I wonder if the method is irrelevant, and that it’s a general problem with getting out values using reference. Thank goodness garbage collection still lives…

#10

It’s a pity there is no consistency.
But that is what it is. For the moment i am trying to create a category on NSFilemanager to do the same thing.
Thanks Shane, knowing it does’t work is also a solution!

#11

That’s so often the hallmark of memory management errors.

#12

I have read that under ARC a release will be set for variables/methods starting with copy, init etc…like copyWriteVar.
Could that not be the problem that copyItemAtPath_toPath_error_ is crashing when reference is used?

#13

It’s an interesting idea, but I’m not sure how that would relate to the reference part. Are you definite that it only happens with copy… methods?

#14

No, i did not test other situations but the copAt… and removeAt…methods. I think there is something happening when the reference keyword is used. When using missing value instead then it’s ok, and that for more methods i think.
I have reported the bug to Apple, so i hope this will help.

#15

FYI, it looks like Xcode 4.6 is also having other problems with ARC.