In my old macOS app, written in Objective-C, I am debugging a reproducible problem in which a file package is removed too early during a system frameworks call. To get a clue, I would like to have the debugger break whenever a file is deleted. To that end, I have set symbolic breakpoints in Xcode at these symbols:
unlink
unlinkat
-[NSFileManager removeItemAtPath:error:]
-[NSFileManager removeItemAtURL:error:]
All of these breakpoints resolve as expected to actual breakpoints, and they break as expected when files are deleted as expected. But during the troublesome too-early file deletion, no break occurs.
Are there any other functions in macOS which can delete files, for which I should add breakpoints?
BACKGROUND INFORMATION:
The problem occurs in my custom NSDocument subclass, when calling [super saveDocument] on a newly-duplicated (as in File > Duplicate) but never-before saved document package. Such document packages reside in ~/Library/Autosave Information/, and when things work properly, remain there until the Save panel appears, and is subsesquently dismissed. However, in the bug case, the package disappears immediately when the user clicks File > Save (or an Auto Save occurs), apparently causing a later error indicating that the deleted package could not be moved to the path returned by the Save Panel.
I also tried changing the POSIX permissions of that package after it appears, and before clicking File > Save, to octal 500. The idea is that it could not be deleted, and I also turned on all of my exception and error breakpoints, hoping the mystery deleter would squawk to the debugger console. Result: The package was not deleted, and, as I had hypothesized, the Save operation succeeded. But nothing squawked. So this mystery deleter is indeed the problem, but is apparently both stealthy and forgiving :(
UPDATE 2019-JUL-19:
After 5 days of finding other things to do, I decided to bite the bullet and use DTrace as suggested Ken Thomases. It worked, showing me that all files in the subject file package were deleted by a call to libsystem_kernel.dylib__unlink, which was in turn called by -[NSFileManager removeItemAtPath:error:].
I do not know why my breakpoints on these functions did not break for these calls, except maybe there is a clue at the bottom of the stack trace, mentioning "xpc". Is it possible that this file deletion is done by an XPC helper process? Does DTrace also probe helper processes of the process being probed? That would be pretty amazing.
Here is an abridged DTrace session transcript:
Air2 jk$ sudo dtrace -n 'syscall::unlink*:entry,syscall::rmdir:entry,syscall::rename:entry { printf("time=%d arg=%s\n", timestamp/1000000000, copyinstr(arg0)); ustack(100); }' -p `pgrep MyApp`
Password:
dtrace: description 'syscall::unlink*:entry,syscall::rmdir:entry,syscall::rename:entry ' matched 4 probes
CPU ID FUNCTION:NAME
1 178 unlink:entry time=6562 arg=/Users/jk/Library/Autosave Information/Unsaved MyApp Document.bmco
libsystem_kernel.dylib`__unlink+0xa
libremovefile.dylib`__removefile_tree_walker+0x147
libremovefile.dylib`removefile+0x99
Foundation`-[NSFilesystemItemRemoveOperation main]+0xba
Foundation`__NSOPERATION_IS_INVOKING_MAIN__+0x11
Foundation`-[NSOperation start]+0x2db
Foundation`-[NSFileManager removeItemAtPath:error:]+0x54
AppKit`__90-[NSDocumentController(NSInternal) _autoreopenDocumentsFromRecords:withCompletionHandler:]_block_invoke_2+0x90
AppKit`__89-[NSDocumentController reopenDocumentForURL:withContentsOfURL:display:completionHandler:]_block_invoke_2+0xa6
AppKit`___NSMainRunLoopPerformBlockInModes_block_invoke+0x19
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__+0xc
CoreFoundation`__CFRunLoopDoBlocks+0x17b
CoreFoundation`__CFRunLoopRun+0xae8
CoreFoundation`CFRunLoopRunSpecific+0x1f3
HIToolbox`RunCurrentEventLoopInMode+0x124
HIToolbox`ReceiveNextEventCommon+0x164
HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter+0x40
AppKit`_DPSNextEvent+0x3de
AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]+0x548
ViewBridge`-[NSViewServiceApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x5f
AppKit`-[NSApplication run]+0x292
AppKit`NSApplicationMain+0x309
libxpc.dylib`_xpc_objc_main.cold.3+0x38
libxpc.dylib`_xpc_objc_main+0x203
libxpc.dylib`_xpc_copy_xpcservice_dictionary
ViewBridge`xpc_connection_handler
ViewBridge`NSViewServiceApplicationMain+0xbff
com.apple.appkit.xpc.openAndSavePanelService`main+0xc0
libdyld.dylib`start+0x1
com.apple.appkit.xpc.openAndSavePanelService`0x1
(The call in that transcript apparently tried to unlink the file package, which I think would have failed since the package was not empty. It is followed by several similar calls which walk the package tree, deleting each node, and finally a repeat of that call to delete the package, apparently with success.)
UPDATE 2019-AUG-06
Although we now know the low-level cause of the problem, we still don't know the high-level cause. I have since discovered that the problem (premature deletion of the temporary document file in ~/Library/Autosave Information) only occurs in macOS 10.15 Beta 4-5 (the current version) and only when the app is built with App Sandbox OFF. When App Sandbox is on, the relevant Autosave Information is in a different location, in the app's container, so this should be a good clue! The problem is easily reproducible with a small demo app, Core Data, document-based, which I have submitted to Apple along with a short video. If anyone has a line to Apple, please direct their attention to FB6937676 !
A rename operation will make the source path no longer refer to a file (looks like the file at the source path was deleted). It can also unlink/delete a file at the destination path, although it will be replaced with the file at the source path. So, that would be rename(), renameat(), renamex_np(), and renameatx_np().
Of course, rmdir() can remove a directory, but only if it's empty.
Apparently, there's a hidden delete() system call. It's described as "delet[ing] a name from the filesystem using Carbon semantics". It's possible the frameworks are using that.
Related
enter image description here
Tried installing and re-installing but of no use.
Every time it says Keyboard Shortcut Conflict for Ctrl+P. But I can't do anything about it as it doesn't open up. I do have keybinder but I don't know how to sort this out.
Inserted Screenshot of exact error message showed. I even tried installing nightly builds but the same error message pops up. every time.
Deleting the user files (only the "keybinding" files) in the directory below then restating CodeBlocks will help if the problem is just because a key conflict:
directory: C:\Users\YourUserName\AppData\Roaming\CodeBlocks\
Depending on the CodeBlocks version, the file names may be something like; cbKeyBinder10.ini, default.cbKeyBinder10.ini, default.cbKeyBinder20.conf
Important note: To be on the safe side, instead of deleting those files immediately, just rename their extensions as .ini_bak or .conf_bak. If this procedure solves your problem, you can, then, delete the backup files. If not, you can rollback your changes by returning the extensions back to their originals.
Whenever I press on the open in IE icon, I get an error in the console:
Error: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIProcess.init]
Source File: chrome://openinie/content/openinie.js
Line: 126 (This happened ever since upgrade to 16.0 and I assume it's probably security related)
I found that js file to be inside some "openinie#wittersworld.com.xpi" file (which I cleverly renamed to zip), and saw the offending line:
var iePath = openinie.getIEPath();
// create an nsILocalFile for the executable
var file = Components.classes["#mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
file.initWithPath(iePath);
// create an nsIProcess
var process = Components.classes["#mozilla.org/process/util;1"].createInstance(Components.interfaces.nsIProcess);
process.init(file); // <-line 126
is it possible to fix it and "re-compile" it zipping and renaming?
(I assume it's something with security maybe).
can I debug this using for example an alert box to display values of variables?
is it possible to fix it and "re-compile" it zipping and renaming
Yes, you can simply replace a file in the ZIP archive, most extensions aren't signed (you can remove the META-INF directory from the XPI file if this one is). In fact, for your debugging it is better to unpack openinie#wittersworld.com.xpi into a directory named openinie#wittersworld.com in the same folder and remove the original file - this way you won't need to pack/unpack on each change. You should also start Firefox with the -purgecaches command line parameter, otherwise the file you are changing might get cached.
can I debug this using for example an alert box to display values of variables?
Yes. However, I would rather recommend Components.utils.reportError() method that will log to the Error Console (press Ctrl-Shift-J to open it) without opening modal dialogs. In this particular case I would write:
Components.utils.reportError(iePath);
This seems to point to a non-existent file meaning that the getIEPath() function is faulty.
Good luck!
How to avoid the window "No source available" while stepping into debug mode on VS2010 SL5
In Tools, Options, Debug, General Page. Check if you have 'Enable .NET Framework source stepping' enabled, if it is enabled, disable.
I tried all the suggested fixes; Nothing worked for me.
I finally figured out the solution after several hours of trial & error iterations.
It turns out that the 'No Source Available' error is due to a stack-overflow within the VS debugger env.
The C/C++ code function that was supposed to be stepped-into (by VS debugger), was using a variable that was initialized to a stack array of a few MB in size. When I replaced this with a heap allocation, VS was successfully able to step into the code.
This worked for me.
Please note that in my case, the actual code (with the stack allocation) ran without a stack-overflow error within the debugger (if I skip the No source available error). It was just that VS's debugger's was not able to step-into a particular function sitting inside another C/CPP file, because of the internal stack overflow.
Hope this helps.
You can hit Shift+F11 to step out and it will complete whatever unavailable function it is in and stop at the next line (it may be unavailable as well, but continue to use Step Out until you get to code you want to examine.)
Regarding VS2019, a description for the issue is provided at MSDocs.
For the requisite vcruntime and ucrt source files, the problem can occur after importing from a previous VS version which has since been uninstalled.
To prevent VS from using the old directories, find the solution property pages and navigate to the Debug Source Files Dialog Box.
Click the tick button to check the entries where any invalid ones can be removed.
The vcruntime and ucrt source should always exist in the directories, and the path at the top of the Browse to find source code dialog should always show the correct path.
In my case, because of a venerable drive bug, it is given to prompt for the "D" drive instead of the "C" drive. Further, the provided path cannot be pasted over to refresh the view, so, if none the wiser, one has to use the dialog to navigate all the way up to the required location from the desktop or equivalent.
Here there is an extension for this issue:
http://erwinmayer.com/labs/visual-studio-2010-extension-disable-no-source-available-tab/
But in my own experience before finding this article (I was in page but I was trying to fix it myself without reading article) I have fixed this problem just by accepting a confirmation message saying something like "Selected source file is different from compiled assembly. Are you sure you want to use this file for debug?". But I can't remember exactly what I did to get this message. I think there was a linklabel which I clicked on "No source available" window and then confirmation message appeared and after confirm the problem ran away.
When trying to restore a version of a document in my document based application, I get an error:
kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList(). Compensating...
kCGErrorFailure: Set a breakpoint # CGErrorBreakpoint() to catch errors as they are logged.
and the document remains unchanged. Also, when this happens, I get a message as soon as I start editing the document telling me:
The document [...] could not be autosaved. The file has been changed by another application.
I think these two problems may be related.
I don't know what to do or "check" because versions just works without any implementation needed; I'm actually confused, because Apple says that I just need to enable autosave in order to restore/revert using versions. Does anyone know what can be causing that error?
Thanks.
I've ran into all of your issues, causing me much pain.
I've gotten that error message regarding kCGErrorFailure... before as well when browsing versions. I've just ignored it mostly as it seems harmless to me. TextEdit seems to spit out this message as well. (Looks like an Apple bug)
For the "document remains unchanged", check here: Restoring from versions browser on OSX lion not working... ideas? (in short, your code for updating your document's UI is probably not being called for the document that is being reverted) (Looks undocumented to me)
For autosaving issues, check here: http://www.cocoabuilder.com/archive/cocoa/306217-how-to-implement-autosaving-browsing-versions-reverting-to-last-saved-in-lion.html (in short, use the file wrapper methods instead for reading and writing). (Looks like an Apple bug)
As well as returning YES to autosavesInPlace: your document needs to at least call updateChangeCount: passing NSChangeDone whenever it changes, so that it "knows" that there are changes to be autosaved.
When I'm searching for something in the Developer Documentation of Xcode, I constantly get "File not Found"/"The requested file was not found in any documentation set."
The odd thing is, it still works. E.g., if I search for NSSound, I can find NSSound.
The error dialogue is invoked whenever it attempts to search as I type, which makes it particularly annoying.
This only happens when I select certain documentation sets (e.g., "iPhone OS 3.1 Library"). I tried deleting it & re-installing, but the same result. (Perhaps I didn't remove everything?)
I put up a post to fix this over here:
http://allens-techlog.blogspot.com/2009/11/fixing-xcode-requested-file-was-not.html
Another fix is to change your searching from "All Doc Sets" to "Apple iPhone OS 3.1". Once you've done that, select the "Apple iPhone OS 3.0" docset. Although it's old you won't get the error and in a month or two you can change it back.
This error is occurring again with Xcode 5+ and Mavericks doc sets. For example:
The requested file cannot be found:
/var/folders/l5/g1r3n28s1v38t5ntjqb_1dq80000gn/T/xcdocui.css.
When it appears try in this order:
Restart Xcode
Log out / log in
Restart
If you don't want to log out or restart, you can delete the temporary parent folder of the CSS file that cannot be found (T stands for 'temporary'), then quit and restart Xcode. But note this will also delete temporary files other running apps might be using, so you might get similar "file cannot be found" messages from other apps, until they are also restarted. Also see this Apple Mailing List post.
I get this problem even in Mavericks and Xcode5, almost 5 years later!
Here's maybe a less scary method than just deleting the rather populated "T" directory:
get out of Xcode. Try not to do anything else either, (who knows what else writes in T?),
but quit Xcode at least.
navigate to the /var/folders/...whatever.../T/.. directory (parent of T)
hide it temporarily with
mv T xT
start up Xcode
look at some doc just to be sure
quit Xcode
look at that same dir; a new T will be there with xcdocui.css in it
cp T/xcdocui.css xT/xcdocui.css
swap it back quickly with rm -rf T ; mv xT T
restart Xcode and see if it works.
"It works for me"
This .css file is kind of small and boring to be causing such a fuss!
That was your early Thanksgiving treat from Apple. They sent a docset 3.1 "update" out about 4-5 days ago and F'ed up alot of peoples documentation. It's basically unusable for me right now...I can't do anything without having do dismiss a never-ending barage of "page not found" error dialogs. It also trashed 50% of the favorites links I had on the left panel of documents. I assume these were from the docsets it now want's me to re-subscribe to but gives an error every time I try.
Haven't seen alot of posts about it yet so I would bet that Apple will likely do nothing. If it were possible to get a human on the phone over there I would have some answers to go along with the frustration.
Happy Thanksgiving
PS. Best to turn OFF the auto-update option in documentation. If not for having that option ON I'd currently be oblivious to this issue and capable of viewing my documentation.
I am getting this as well. I am guessing it is not affecting very many people though, since searching "the requested file was not found in any documentation set" in google is still only turning up four hits. And it is affecting my desktop but not my laptop.
Have either of you tried reinstalling Xcode?