I wish to know how can I trace an application on why it crash and etc if I do not have the source code and Window 7 Event Log is not able to provide me with not much info beside telling me "Application Hang"? Is there any software out there allows me to do so? Thanks!
Related
During 10.8 times I created macro in Keyboard Maestro for adding web pages to Reminders list to read them later.
In Mountain Lion and Maverics it worked fine but in Yosemite something wrong is going on resulting very slow executions.
Previously execution time was about 1-2 seconds now its over 40 seconds or even one minute!
Apple team provided me with wrong solution ordered to "code sign" my script, but there is no "file" to codesign and applescripts can be executed in command line. So IMO they messed up something in osascript and still couldn't fix it till 10.10.4. But I need someone to confirm or to advice me how to debug problem, because I cannot find in system console log lines relevant to problem.
UPDATE:
On El Capitan 10.11.1 problem still persist.
Macro
Could anyone test and confirm this? I provided link to macro.
It is bind currently to F1 - change as you like. Before execution create "2Read" list in Reminders on OSX.
I've tried it and it's done in about 1-2 seconds on my machine. So I do not experience the same problem as you.
I'm running OS X 10.10.4 on a late 2013 MBP Retina.
Maybe your "2Read" list is too long?
Another tip:
I used to have a problem with long lists in Applescript, too. Sometimes it would take minutes to run through a list, but after using some if these tips the time for the lists was brought back to only seconds.
From your pastebin link (yeah, I did warn you it'd look like mince):
Keyboard Maestro event logs
(1) KM sends an 'open' event ('aevt/odoc') to Growl, telling it to open a temp file (presumably to make Growl display a message)
(2) Bartender sends a 'get scripting terminology' event ('ascr/gdut') to KM
(3) Bartender sends a 'BTDR/Load' event to KM, which looks like Bt telling KM to load a plugin named "BartenderHelperNinetyOne.bbundle"
(4) KM send a 'KeyC/KeyB' event to something (it doesn't give the name of the process, only its Process Serial Number, which is the classic MacOS equivalent to a Unix process ID). Probably easiest just to ask the KM devs about that one.
(5,6,7) KM then sends three 'application died' events ('aevt/obit') to Keyboard Maestro Engine (I'm guessing that's a faceless helper app that runs constantly in the background), informing it that three osascript processes (PSNs 312312, 315315, 316316) have terminated. This doesn't necessarily mean that osascript has crashed as those events contain an error number ('errn') parameter with value 0, and command-line processes normally return error code 0 to indicate they've completed successfully. It's quite likely these are normal internal notifications sent between KM and KME to indicate when a task is completed. The first of those osascript processes (PSN 312312) is related to the Reminders activity below; the other two I'm guessing are you running other AppleScript macros and probably not relevant here.
Reminders event logs
(1,2,3) The 'osascript' process with PSN 312312 sends Reminders a 'make' ('core/crel') event and two 'set' ('core/setd') events, which is obviously your AppleScript being run.
(4) The Dock sends it a 'reopen' ('aevt/rapp') event, which is probably just you clicking on Reminders' dock icon to bring it to the front.
The main problem, of course, is that without timestamps I can't tell you where your 40-second delay is occurring. You'd really need to do it again, this time manually noting the time at which each message is logged. And if you see a single 40-second delay somewhere in the middle, it should easy enough to determine which events it's occurring inbetween, which should start to point towards a cause. At which point, you're probably best contacting the KM vendor to discuss it with them.
HTH
I'm investigating whether I can get better performance from asl_log than NSLog on iPhone/iOS (probably...) but I'm stuck at a point where it doesn't seem that asl's log output will show up in the System Console (as viewable by a number of apps like System Console, iConsole, etc). I know that I'm setting it up right since I open with ASL_OPT_STDERR, and I see the log entries in XCode when the device is tethered.
I've explored lots of interesting stuff online (e.g. http://boredzo.org/blog/archives/2008-01-20/asl-logging, https://github.com/robbiehanson/CocoaLumberjack) and the best hope seemed to be asl_open() with Facility of "com.apple.console" but alas, the output still doesn't show up in Console. Is NSLog the only option?
Add STDERR to ASL and then it shows up in the console
asl_add_log_file(NULL, STDERR_FILENO);
You need to set read privileges on the message, using either ReadUID or ReadGID. Setting either to -1 will allow any user/group to view the message according to the header file documentation.
aslmsg msg = asl_new(ASL_TYPE_MSG);
asl_set(msg, ASL_KEY_READ_UID, "-1");
asl_log(NULL, msg, ASL_LEVEL_NOTICE, "Hello, world!");
asl_free(msg);
The following message keeps getting logged to the console:
-[__NSCFSet minusSet:]: This app appears to be calling this method with
a non-set parameter. Please wait while the system corrects this...
I don't know what I did to this appear. I never call this function and don't know what things call this.
For me, this appear when a touch anything in my UIWebView. This can be a touch in text box, or just a simple touch in any area of the page. Any new touch will produce it.
Anyone have an idea how to solve it?
You should be able to find out whether your code is causing the log message or not. You can do this by interrupting the app when the message is logged and looking at the stack backtrace of the logging thread. Then, investigate what code created the object that is prompting the log message using malloc history or Instruments.
To start with, you can try adding a symbolic breakpoint on -[__NSCFSet minusSet:]. You could narrow it down to the actual code doing the logging if you looked at the disassembly for a call to NSLog and placed the breakpoint there.
Once you've ruled out your code, it's not your fault: it's time to file a bug report and move on. If the log messages are swamping more interesting log messages, you might try patching the binary so it doesn't log, but just living with it is likely to be easier (though much less fun).
I wanted to know do we need to log the exceptions/errors in a common file in file system when an iPhone application runs for debugging purpose later point in time? Or this is handled by IOS automatically through device logs?
I now using NSLog statements we can print on consol but is there something similar to log4j in Java where you put all debugging statements including errors/exceptions in a single file which you can analyze later point in time.
What is the best way to handle such scenarios.
Some excellent info is found in this previous post on SO:
Logging to a file on the iPhone
Another good tip for logging in general is using the DLog macro:
http://iphoneincubator.com/blog/debugging/the-evolution-of-a-replacement-for-nslog
I have an AIR application that takes command-line arguments via onInvoke. All is good, but I cannot figure out how to print some status messages back to the user (to stdout / console, so to speak). Is it possible?
Even a default log file for traces would be fine, but I can't find any info about it anywhere. Do I need to create my own log file? Now that'd be silly.
Take a look at CommandProxy. It is a low level wrapper around your AIR application that lets you send command from AS3 back to the proxy for communicating with the underlying OS. You should be able to add a means of writing to the command line via such a method.
I don't think that is possible, but I'm not completely sure though.
There is a flashlog.txt file which you can configure so all trace() statements are logged to it. Check this post http://www.digitalflipbook.com/archives/2005/07/trace_from_the.php for more info on how to set it up. This is for logging from the browser, but I'm pretty sure it should also work from an air app.
Additionally, you could use SOS MAX from Powerflasher to log to an external console through an XML socket.
By default, trace() will output to stdout.
Your AIR application is one, big trace window if you want it to be.