Electrolysis/FAQ

I'm trying to make new code use IPDL, and headers like IPCMessageUtils.h are missing...

In every directory which needs to use IPDL protocols, the Makefile.in should include chromium-config.mk like this:

include $(topsrcdir)/config/config.mk
include $(topsrcdir)/ipc/chromium/chromium-config.mk
include $(topsrcdir)/config/rules.mk

See e.g. content/base/src: http://hg.mozilla.org/projects/electrolysis/file/c3b494310a9f/content/base/src/Makefile.in#l187

How do I test the multi-process plugins?

To test multi-process plugins, set the pref dom.ipc.plugins.enabled to true... you can do this from about:config in the browser.

Why doesn't flash work with my x86_64 Linux build?

Most likely because you're trying to use x86 flash, which has been observed failing with Electrolysis x86_64. You're probably seeing an error like

 Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64

If so, use the "64-bit flash plugin for Linux" instead.

I can't get Electrolysis to build on Mac.

Indeed. Electrolysis doesn't build on mac yet.

Why do I get weird segmentation faults after I change something in an .idl file ?

When you change what's exposed in an .idl file, it's not sufficient to rebuild only the stuff that you're working on and that you know is using that XPCOM component. Indeed, many other parts of the codebase might be using it too. So these segmentation faults arise from those not-rebuilt objects having out-of-date vtables of the updated idl interface.

In order to solve the problem, you'll have to rebuild FROM TOP every time you change something in an interface.

I get an error like "Error: Value error: message was deserialized, but contained an illegal value". Help!

This error means that an IPDL message handler had a problem processing a received message. Currently, this means either

1. the message contained a value that IPDL could deserialize, but was semantically invalid. For example, an invalid actor ID
2. the C++ Recv*() or Answer*() handler returned false, i.e., couldn't process the message

NOTE: case (2) has been caused in the past by returning an nsresult from a Recv*()/Answer*() handler. Don't do that! The handlers should return booleans, and nsresults get implicitly converted into booleans in exactly the wrong way.

One way to find out which message is causing this error is to turn on detailed IPC message logging, by setting the environment variable MOZ_IPC_MESSAGE_LOG=1 before launching e10s.