Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of drkemp@google.com designates
 209.85.219.52 as permitted sender)
MIME-Version: 1.0
Date: Mon, 29 Jul 2013 13:58:36 -0400
Message-ID: 
 <CAMTxO41ke47gsv6psgY1TA+-YvZsMOjZ6mNHQNiJHqQ8mzrbTQ@mail.gmail.com>
Subject: Android Bridge -processMessage error
From: David Kemp <drkemp@google.com>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=001a1133050cce955b04e2aa3de9

--001a1133050cce955b04e2aa3de9
Content-Type: text/plain; charset=ISO-8859-1

I have encountered a problem twice where the bridge throws an error on the
JS side and continues to attempt to process the message forever. It
generates 10s of thousands of log message that say :

processMessage failed: Error: ....
CB-4005 may also be reporting the same issue, but in that case I suspect it
was a mismatch of js version/native.

I do not have a reliable real-world test case that makes this happen.

While I was working on instrumenting the bridge for some profiling, i
created the same issue. In my case it was because the message length
contained in the message was one byte shorter than the actual message (my
bad). The result of that is that the offending message is tossed, but the
last character remains in the message buffer. on the next message cycle,
that last character causes a null message to be obtained, and leaves the
offending character in the message queue.(cycle continues forever...)
I will post a pull request to fix part of the problem. It easy to detect
the message corruption and prevent the infinite message loop. that may at
least make it easier to find out what the original message error is. The
proposed change will not fix the actual issue that makes the message length
wrong, just makes it easier to find.

--001a1133050cce955b04e2aa3de9--