Error calling method on NPObject!
When a plugin crashes, content script may still have a reference to JS objects provided by that plugin. The JS objects will throw an exception “Error calling method on NPObject” when any properties or methods are called. Unfortunately, this generic error message is also thrown whenever a plugin method fails for any reason. You can’t tell, just by looking at the exception, whether the process crashed or some other type of failure occurred.
This is important when a test fails: there could be any number of different errors lurking under the surface with similar outward appearance. Today there was a Mochitest error with the following symptoms:
197 ERROR TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_painting.html | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - Error calling method on NPObject! at http://localhost:8888/tests/modules/plugin/test/test_painting.html:105 PROCESS-CRASH | automation.py | application crashed (minidump found) Thread 1 (crashed) PROCESS-CRASH | automation.py | application crashed (minidump found) Thread 1 (crashed) PROCESS-CRASH | automation.py | application crashed (minidump found) Thread 1 (crashed) PROCESS-CRASH | automation.py | application crashed (minidump found) Thread 1 (crashed)
Reading through the log, however, the important output is:
###!!! [RPCChannel][Child][/builds/moz2_slave/mozilla-central-linux/build/ipc/glue/RPCChannel.cpp:276] Assertion (mDeferred.empty() || 1 == mDeferred.size()) failed. expected mDeferred to have 0 or 1 items, but it has %lu (triggered by rpc) local RPC stack size: 2863316886 remote RPC stack guess: 8 deferred stack size: 2863316886 out-of-turn RPC replies stack size: 2863316886 Pending queue size: 2863317142, front to back:
This assertion is immediately followed by an abort, which is visible in the crash dump output also:
Crash reason: SIGSEGV Crash address: 0xbdce4804 Thread 1 (crashed) 0 libxul.so!mozilla::ipc::RPCChannel::DebugAbort(char const*, int, char const*, char const*, char const*, bool) [ipc_message.h:0235fc257969 : 97 + 0x0]
David B. mistakenly thought that this was a manifestation of Bug 541102 when in fact it is an entirely unrelated bug with similar symptoms. When in doubt about a crash, please check with one of the Electrolysis team to help diagnose and read the log.
January 26th, 2010 at 8:57 am
How about just improving the error message?
I’ve found that improving the quality of the message in the exceptions I generate, and adding some relevant contextual information makes finding bugs a whole lot faster.
For example, “index 5 is out of bounds” is a much better exception than “index out of bounds” or “range error”