How can I put log statements into a browser plugin written for Mac OS X so that I can see them when the plugin is running?
Any printf you put in your browser plugin will eventually show up in the "console" application; however, recently that seems to take longer and longer and sometimes doesn't end up showing up at all.
I personally recommend logging to a file; the FireBreath project has built-in support for log4cplus so a lot of us use that, but there are plenty of logging statements.
Still, even just a printf will usually be visible if you look in the right place -- and that's the system log, which you can view by running Console.app (in Applications/Utilities)
Related
I can not run any program.
As per the instruction I went to vscode dev.
Open up my repository to run a test program.
However, unfortunately, I can not run any of my programs.
I have checked the doctrine which said that only chrome and edge are supported.
But I can not run my program on the terminal window because it tells the code can only run on environments such as codespaces, and local vs code.
What do I miss so that the problem is occurring?
As VSCode(.dev) issue 166506 illustrates, you cannot access terminal from your browser probably because that menu entry was hidden/removed on purpose.
With VSCode 1.75 (Jan. 2023), it will be restored with an explanation.
I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that vscode.dev was a browser application.
Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of vscode.dev through our welcome views.
The message is the one you saw:
Terminal are not available in the web editor.
To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code.
You can develop remotely, but you need to execute locally.
I've hooked the system call to typedef int (*orig_open_f_type)(const char *__file, int __oflag, ...); and thus, whenever a file gets opened, my code gets the event before it is passed on to the system. I created a dynamic library that overrides the open call and inject this library using DYLD_INSERT_LIBRARIES - working on a Mac machine and using XCode. It is a standard step that enables me to hook calls.
Now, I have bash script in which I have some files that I want to open. I have tried xdg-open , cat, exec - but they are not triggering the system call to open the file.
How should I invoke this open call in my bash script?
Please note that I have tested my open call hook, by opening files in C code.
I believe you're running foul of Apple's SIP (System Integrity Protection) which is designed to stop people doing things like that with system-provided executables. SIP was added to Mac OS X El Capitan (10.11) and continues in macOS Sierra (10.12).
To demonstrate whether this is the problem, consider copying /bin/cat to /usr/local/bin/cat and then try hooking (running) the local copy. You might get away with it there. This 'workaround' is purely for demonstration purposes. Basically, if I'm right, SIP is Apple's way of saying "don't go messing with our software".
You can follow links from Can Mac OS X El Capitan run software compiled for Yosemite that expects libraries in /usr/gnu/lib? to find out more about SIP. Following links via What is the "rootless" feature in El Capitan, really? on Ask Different to a blog article on System Integrity Protection, it says explicitly:
Runtime protection
SIP’s protections are not limited to protecting the system from filesystem changes. There are also system calls which are now restricted in their functionality.
task_for_pid() / processor_set_tasks() fail with EPERM
Mach special ports are reset on exec(2)
dyld environment variables are ignored
DTrace probes unavailable
However, SIP does not block inspection by the developer of their own applications while they’re being developed. Xcode’s tools will continue to allow apps to be inspected and debugged during the development process.
For more details on this, I recommend taking a look at Apple’s developer documentation for SIP.
Emphasis added
Basically, this means that you won't be able to hook calls to the open() system call for Apple-supplied software installed in the system directories. You will need to rethink what you are trying to do.
Running any normal command -- like cat -- that processes a file will cause the file to be opened. You can also open a file (and immediately close it) using the shell syntax:
: < /path/to/file
If your system call hook isn't getting called, something must be wrong with your hook -- there's no way these commands are working without opening the file. Alas, you haven't explained how you implemented your hook, so we have no way of debugging that.
The file command opens the file to look at its contents.
$ file /path/to/file
I have suggested this because it eventually leads to having the system call open which can be confirmed using strace.
$ strace file /path/to/file 2>&1 | grep open
I thought one of the good things about using file is that it opens the file in read only mode. In comparison to other ideas, unlike cat, it will not have to run through the entire file, just part of it, so the time complexity using file may be constant. Unlike vim, which someone has suggested, file will return when finished and not block like a text editor would.
I sent my first desktop OSX app out to a small circle of testers today. One user cannot get past the splash screen.
I am wondering how one might debug something like this? Would I somehow write NSLogs to a file? Or does OS X have some sort of utility? I assume I need some sort of logging capability, right?
You can write your logs to file quite easily (not via NSLog, but just plain writing NSString to disk via writeToFile if you want to). You can also have your logs automatically uploaded to your server if you have one using NSURLConnection with a POST.
I prefer the latter because it requires little intervention from the testers, and happens automatically.
Distribution builds are not ment to be debugged or else it would have been development build.
You can how ever sync your device with itunes and then get the crash report(if you want to know the source of crash).from appdata.
reffer to this link. if you want to debug make a debug build with development provisoning. in your case ask the tester to send you the crash report and you keep the ipa or app file safe you will need it to read the crash report.
It used to be that stdout went to the console log, displayed by Console.app. I've been having some problems with a firefox plugin (see other questions, sorry about the spam...) and I was trying to use printfs to at least see if I was STARTING my plugin.
I just noticed today that my console log hasn't been updated since January 6. (Yes, I've been using the machine for the past month.) Now, I'm not the only program that uses the console log, so all those messages must be going SOMEWHERE else.
Does anyone know where?
The problem was that syslogd was broken. It's fixed now.
Solution: the problem wasn't that stdout wasn't going to the console. The problem was that the console wasn't getting written to because syslogd was buggered. Syslogd was being sandboxed for some reason, and so NOTHING had been written to the console since January 6.
the solution was to re-comment out the "uncomment this if you want to sandbox syslogd" section of LaunchDaemons/com.apple.syslogd.plist.
The solution came from superuser.com....
thanks!
printf should be going to the Console.app. It sounds like yours is broken.
A good way to debug your plugin would be to set FireFox as your XCode project's Custom Executable, and run in the debugger. Then the XCode Console would catch the output.
In that case you also just use a breakpoint to see if your plugin was loading instead of printf.
After starting an app and running "lsof | grep <program_name>" it shows file descriptors 0, 1 and 2 are all /dev/null
I've got a user reporting crashes in my Mac OS X application, and their console logs report the following:
Symbolication warning: error parsing FDE at 0x100052649 in:\n
Does anyone have any insight into what this might be? I assume that somehow the symbols have been stripped from my app in a way that gets in the way of Mac OS X's crash reporter, but I've not seen it before.
I can honestly say that I have never seen this one before. I have seen a number of other dynamic linking problems just not this one. If the user is amenable to helping you with this defect, you might want to write a shell script to enable some dynamic linking environment variables and then launch your application.
#! /bin/bash
export DYLD_PRINT_LIBRARIES=1
export DYLD_PRINT_LIBRARIES_POST_LAUNCH=1
export DYLD_PRINT_APIS=1
export DYLD_PRINT_BINDINGS=1
export DYLD_PRINT_DOFS=1
open -a Console.app > /tmp/link-log 2>&1
The output log might provide some hint as to what is going on. You could also capture the output of otool and other command line utilities to check for unexpected libraries and what not.
You might want to google Symbolication to get a better handle of what is going on here. I came across an interesting chunk of code from Darwin that points this to a dynamic symbol lookup warning. There is also a utility called Shark that may be of interest as well.
Good luck...
I just found this topic via Google because I'm having the same problem. The StarCraft installer crashes immediately. It points to /usr/libexec/oah/translate, which seems to work perfectly well. My guess is this has something to do with the fact the computer it doesn't work on runs iDeneb 1.3 (aka Mac OS X 86 for use on non-Apple hardware), whereas the computer that can run the application just fine has a genuine version of Leopard.