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.
Related
I am not aware that I changed (not even saved it differently) anything in the workflow, but the content of all containers changed to "Delegate: Body" (see picture):
The Robot works, nevertheless it is not so confortable because also preview pictures disapear, in Selector is only the window for text and I cannot validate it.
Does anyone have an idea how to turn it back?
Edit: there is result of search for packages:
This is due to the fact that the designers didn't load. It's most likely a bug. Does it happen even if you close and re-open the project?
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.
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
I'm developing an epub reader with monocle (https://github.com/joseph/Monocle) which is launched in a uiwebview. My problem is that when I try to copy some text, like what we would do in any other uiwebview, it doesn't seems to do anything... well, I get Webcore NSBeep()! in output view.
any idea or approach?
Webcore NSBeep()! is a error notification, because when you try to copy text from UIWebview the text is not copied into your clipboard and the error notified using a beep (IMHO which is not wise way of notifying errorr by any platform, it would have been any visual indication)
And please note : NSBeep() is part of the ApplicationKit framework which doesn't exist on the iPhone.
I had the same strange issue, irritatingly enough everything worked for quite some time. Then with some changes, this error happened. Reverting the code did not help. After a whole day searching and thinking, I still don't know what caused this, but I know that it wasn't my code!
My theory is that either my git repository was somehow messed up or it was because I edited my project with a beta version of the IDE+SDK. Either way, you should probably look into recreating your webview in InterfaceBuilder. Or recreate your project (or at least partially to confirm that it might be a bug in the project itself). I think/hope that the error will go away then.
I am working on a new version of a firefox extension, but after releasing it, and incrementing the em:version in install.rdf and update.rdf, when I click "Find updates" Firefox reports that "No updates were found." When I run it with debugging on, the output in the console is actually identical to what I see when I don't put the update live.
It starts with RDFItemUpdater:checkForUpdates with all of the parameters, and returns with Addon Update Ended and status: 8.
I verified with McCoy tool that the extension is signed, and has the same Id as the old one, etc. I'm not sure what else to try. Any advice would be appreciated. This is with Firefox 3 (and the extension is marked as compatible with it... that didn't change).
Make sure your update.rdf file is being served with an appropriate Content-Type, i.e. text/rdf, text/xml or application/xml+rdf
If you've only recently changed update.rdf, maybe it's cached. Load it in the browser then Shift-Refresh.
here are some nice tips that helped me: https://developer.mozilla.org/en/Extension_Versioning,_Update_and_Compatibility
but, auto update function will not work if extension is marked "experimental".
I'm having a similar issue, and think it's due to an invalid rdf file. Did you check that yours parsed with this tool? http://www.w3.org/RDF/Validator/
There are lots of things to mess up, one of which is installing an extension from AMO and expecting it to update when you change your update.rdf :)
I was having the same problem. In my update.rdf, I had a wildcard in my minVersion attribute:
minVersion="3.0.*"
Removing the wildcard fixed the status 8:
minVersion="3.0"
The update works now (console shows status 1). This was using Firefox 3.0.18.
My guess is that status 8 means there was a problem understanding the contents of the file (not necessarily an RDF parsing problem). If your minVersion doesn't have a wildcard, maybe there's an invalid character hiding somewhere.