Would like a way to view WebKit2 IPC messages sent between processes

[Adam Roben (:aroben)]

It would be nice for debugging to have a way to view CoreIPC messages sent between processes. Perhaps a separate process, similar in spirit to Spy++, could do it. You could point the "WebKit2Spy" at the UI process, and it would communicate with the UI process to find all the CoreIPC::Connections it's using to communicate with other processes.

[Adam Roben (:aroben)]

We could use our message-generation scripts to generate code to turn a message into a string for display in WebKit2Spy.

[Adam Roben (:aroben)]

Another option would be to use something like Event Tracing for Windows to log the messages that a process sends and receives. But that wouldn't be very cross-platform-friendly.

[Keith Rosenblatt]

Created attachment 90217 [details]
Propsed Core IPC message logging (w/ build flag)

[WebKit Review Bot]

Attachment 90217 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/ChangeLog', u'Source..." exit_code: 1

Source/JavaScriptCore/ChangeLog:10:  Line contains tab character.  [whitespace/tab] [5]
Tools/ChangeLog:10:  Line contains tab character.  [whitespace/tab] [5]
Total errors found: 2 in 67 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Keith Rosenblatt]

Created attachment 90221 [details]
Proposed Core IPC message logging (w/ build flag, corrected changelog style)

[Anders Carlsson]

Comment on attachment 90221 [details]
Proposed Core IPC message logging (w/ build flag, corrected changelog style)

It's great that someone's thinking about CoreIPC message logging. Thanks for working on this, Keith!

I just talked to Sam Weinig and we'd like to go a somewhat different route:

- As with the rest of the WebKit2 logging, we'd like this to be compiled by default and controlled by a runtime flag.
- We'd like a solution that's less intrusive and doesn't require adding extra functions to every object that could receive a message.
- We'd also like to be able to log the message arguments.

A better design would be to just log the messages in the generated message receiver implementations (For example WebPage::didReceiveWebPageMessage). Basically, something like:


void WebPage::didReceiveWebPageMessage(CoreIPC::Connection* connection, CoreIPC::MessageID messageID, CoreIPC::ArgumentDecoder* arguments)
{
    MessageLogger logger(connection->isMessageLoggingEnabled());

    switch (messageID.get<Messages::WebPage::Kind>()) {
    case Messages::WebPage::SetActiveID:
        logger.setMessage(messageID, "WebPage", "SetActive");
        CoreIPC::handleMessage<Messages::WebPage::SetActive>(arguments, this, &WebPage::setActive, logger);
        return;
    ...
}

The MessageLogger destructor would then output the message if logging was enabled.

We could add a log member function to our various Arguments classes that would log the argument values; this would be called from within handleMessage. (I don't think the argument logging is necessary)

Again, thanks for working on this! I hope you'll like the design as much as we do :)

[Keith Rosenblatt]

Thank you for the quick review and the comments.  Your suggestions make a lot of sense to me.  It would be far better to not require additional code be added for any new message receiving class.  I will continue work on this.

[Radar WebKit Bug Importer]

<rdar://problem/9815700>

[Adam Roben (:aroben)]

Anders and I discussed this a little more the other day. We talked about having a separate CoreIPC logging application rather than just dumping messages to the console. The logging application would somehow connect to the applications to be logged via a CoreIPC connection. Information about sent and received messages would be packaged up in some standard format (probably a dictionary) and sent over the connection to the logging application.

[Adam Roben (:aroben)]

Here's a brain dump of some more thinking I've done on this:

It would be good for the logging application to be written in a cross-platform way so that all ports can use it. A few techniques could be used to accomplish this:

1) The logging application's UI can be written in HTML/CSS/JS.

2) The logic for finding and connecting to processes to be logged can be inside WebKit2 itself and exposed via an API/SPI that the logging application uses.

For example, the logging application can instantiate a WKIPCLoggingServer and set itself as the server's client. The server would take care of finding applications to log and telling the client about them. The client can then choose an application to log and start receiving messages from it.

3) Messages should have a platform-agnositic "logging representation" which can be handed to the logging application via the proposed logging API/SPI.

The logging representation could be a WKDictionary with standard keys/values, or a more specific object.