Log messages

[Paul Krueger]

While doing Mac app development using 1.10-dev-r16162-trunk I noticed that there are a large number of messages logged that appear to be tracking Core Graphics lib calls. This doesn’t hurt anything, but I’m wondering if somebody turned on some sort of debugging code that is creating the log entries. I’m doing the same sort of thing in my own code, which is how I discovered this. Is there any way to turn off this output?

Log output looks like:

9/15/14 3:46:02.032 PM dx86cl64[68550]: CGSGetWindowTransformAtPlacement
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSTranslatePointForWindow
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSGetWindowBounds
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSGetWindowTransformAtPlacement
9/15/14 3:46:02.034 PM dx86cl64[68550]: CGSTranslatePointForWindow
9/15/14 3:46:02.034 PM dx86cl64[68550]: CGSGetWindowBounds

with LOTS more of the same.

[R. Matthew Emerson]

Post by Paul Krueger
While doing Mac app development using 1.10-dev-r16162-trunk I noticed that there are a large number of messages logged that appear to be tracking Core Graphics lib calls. This doesn’t hurt anything, but I’m wondering if somebody turned on some sort of debugging code that is creating the log entries. I’m doing the same sort of thing in my own code, which is how I discovered this. Is there any way to turn off this output?
9/15/14 3:46:02.032 PM dx86cl64[68550]: CGSGetWindowTransformAtPlacement
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSTranslatePointForWindow
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSGetWindowBounds
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSGetWindowTransformAtPlacement
9/15/14 3:46:02.034 PM dx86cl64[68550]: CGSTranslatePointForWindow
9/15/14 3:46:02.034 PM dx86cl64[68550]: CGSGetWindowBounds
with LOTS more of the same.

I don't think we did anything to turn on that sort of logging. At least I don't remember doing anything like that myself.

You could attach the debugger to the lisp and set a breakpoint on NSLog.

With lldb you'd do:

$ lldb
attach <pid of ccl>
process handle --notify false --pass true --stop false SIGKILL SIGILL SIGSEGV SIGBUS SIGFPE SIGUSR1 SIGUSR2 SIGEMT
b NSLog
cont

and then wait for the NSLog breakpoint to be hit. The "bt" command will show a backtrace. If the NSLog was called from lisp, you'll just see SPffcall as the caller. Otherwise, maybe the backtrace will give you a clue where the log message is coming from.

[Paul Krueger]

Post by R. Matthew Emerson

Post by Paul Krueger
While doing Mac app development using 1.10-dev-r16162-trunk I noticed that there are a large number of messages logged that appear to be tracking Core Graphics lib calls. This doesn’t hurt anything, but I’m wondering if somebody turned on some sort of debugging code that is creating the log entries. I’m doing the same sort of thing in my own code, which is how I discovered this. Is there any way to turn off this output?
9/15/14 3:46:02.032 PM dx86cl64[68550]: CGSGetWindowTransformAtPlacement
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSTranslatePointForWindow
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSGetWindowBounds
9/15/14 3:46:02.033 PM dx86cl64[68550]: CGSGetWindowTransformAtPlacement
9/15/14 3:46:02.034 PM dx86cl64[68550]: CGSTranslatePointForWindow
9/15/14 3:46:02.034 PM dx86cl64[68550]: CGSGetWindowBounds
with LOTS more of the same.

I don't think we did anything to turn on that sort of logging. At least I don't remember doing anything like that myself.
You could attach the debugger to the lisp and set a breakpoint on NSLog.
$ lldb
attach <pid of ccl>
process handle --notify false --pass true --stop false SIGKILL SIGILL SIGSEGV SIGBUS SIGFPE SIGUSR1 SIGUSR2 SIGEMT
b NSLog
cont
and then wait for the NSLog breakpoint to be hit. The "bt" command will show a backtrace. If the NSLog was called from lisp, you'll just see SPffcall as the caller. Otherwise, maybe the backtrace will give you a clue where the log message is coming from.

No break was taken and the log messages kept coming, which I suppose tells us that they’re not coming from an NSLog call, but rather from something down lower. I’ll do a little research to see if I can discover anything on the web anywhere.

Thanks for the help.

By the way, I’ve discovered more problems with my contrib, but I haven’t resolved them all yet and don’t expect you to hold up the release for my fixes. Bummer.