Getting Lumberjack messages to Instruments Console?

[rsebbe]

Hi,

I'm using CocoaLumberjack and it's great. One inconvenience I found recently was that I wouldn't get output when the app is launched within Instruments. It actually logs to Console.app, but I'd like to see the output directly within Instruments as it allows to correlate with other recorded data.

The app is set up with both ASL and TTY loggers.

Any idea of what is wrong in my setup?

Thanks!

Raphael

[Robbie Hanson]

Temporary fix:

Go to DDTTYLogger's initialize method, and change this:

isaTTY = isatty(STDERR_FILENO);

to this:

isaTTY = YES;

-Robbie Hanson

--
You received this message because you are subscribed to the Google Groups "CocoaLumberjack" group.
To view this discussion on the web visit https://groups.google.com/d/msg/cocoalumberjack/-/-glwMWEmV2MJ.
To post to this group, send email to cocoalu...@googlegroups.com.
To unsubscribe from this group, send email to cocoalumberja...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cocoalumberjack?hl=en.

[Raphael Sebbe]

Hi Robbie,

Just tried it, and yes that works. Thanks!

But in that case, does that mean it will also output in Console through stderr, in addition to ASL if both are setup?

Do you see other reasons to not use this fix in deployed apps?

Thanks,

Raphael

[Robbie Hanson]

Fair question. Some explanation is needed.

So, what does NSLog do?  It does two things. First it sends your log message to the Apple System Logger. This is essentially a daemon process that takes log entries and writes them to a system database. You can browse this database via Console.app on Mac OS X. But, this doesn't actually display anything on screen. So then NSLog does the usual writing to stderr. And it's this step that causes it to be written to screen.

With Lumberjack, things are a bit more flexible and transparent. Try disabling the TTY logger in your setup. You'll notice you still see your log statements in Console.app. Or, if iOS, in the device log via Xcode (in organizer). But you won't see anything in Xcode's console while debugging. Now try the reverse. Enable TTY, but disable ASL. Now you'll see output while debugging in Xcode. But your logs will be absent from system log in organizer.

You can capitalize on this for performance. For example, see no need for ASL? Don't enable it. Prefer dedicated log files on iOS where you don't have to worry about truncation due to the super short history the OS seems to keep/display. No problem. A few lines of code and you're done.

Now concerning stderr. This is just a file descriptor within your application. Think of it like a socket or pipe. The other end goes somewhere, but you don't really need to worry about where. If you launch your app on the command line, the pipe gets printed out to the terminal. If launched via Xcode, the pipe goes to the Xcode console. If launched normally (e.g. Double-click in finder, or tap on app to launch on iOS.), then the pipe may go to /dev/null (meaning you can write to it, but the bytes simply go nowhere). Some people will even remap stderr to a log file. It's a crude form of logging, but it works in a pinch.

Under most circumstances, one can ask the system if stderr is going someplace. This is what I've done with the isaTTY variable. It was, in theory, a nice little optimization. All the work required to format and print the log statement gets skipped. However, as you've noticed, it's not always reliable. So I will likely remove the isaTTY variable. As you know, logging to /dev/null doesn't hurt anything, and happens all the time. However, one can still optimize. Just don't enable TTY logger when compiling in release mode.

-Robbie Hanson

Sent from my iPhone

[Raphael Sebbe]

Hi Robbie,

thank you very much for that detailed explanation. CocoaLumberjack is indeed very flexible.

The problem is then maybe that Instruments plugs in the app's stderr at a later time than when TTY logger gets initialized.

The thing is, we need a Release build in Instruments, as it makes more sense to analyse that way, performance-wise.

Anyway, we got some code above that to filter out verbose logs (unless user activated), so it just makes sense to always skip the isatty() check.

Thank you!

Raphael

[Robbie Hanson]

The problem is then maybe that Instruments plugs in the app's stderr at a later time than when TTY logger gets initialized.

I thought this too. I added a dispatch_after that ran 10 seconds later, and checked isatty again. It still returned NO.

The thing is, we need a Release build in Instruments

When I said, "don't enable TTY logger when compiling in release mode", I just meant "if you don't need it, then one could possibly optimize this way". Of course if you need it, then certainly keep it enabled in your release builds.

-Robbie Hanson