Avoid passing NULL channel to message library.

I've looked at this code countless times, and can't come up with
an explanation for why the bug happens without resorting to
time drifts, quantum physics and possible questionable behavior
of the glib main loop implementation. So just avoid the issue
by having an explicit check.

I've never been able to hit it myself either, to get a good
debug session going on, and the cores I've seen have been
less than helpful.

Signed-off-by: Marcelo Vanzin <mvanzin@vmware.com>

diff --git a/open-vm-tools/lib/rpcIn/rpcin.c b/open-vm-tools/lib/rpcIn/rpcin.c
index 25d9251e936461e5f23a329a11ba7022af9d2bd4..23e2569b4f2332e96ad12429f359cb21dc9df7e1 100644 (file)
--- a/open-vm-tools/lib/rpcIn/rpcin.c
+++ b/open-vm-tools/lib/rpcIn/rpcin.c
@@ -589,6 +589,15 @@ RpcInLoop(void *clientData) // IN
 
    in->inLoop = TRUE;
 
+   /*
+    * Workaround for bug 780404. Remove if we ever figure out the root cause.
+    * Note that the ASSERT above catches this on non-release builds.
+    */
+   if (in->channel == NULL) {
+      errmsg = "RpcIn: Channel is not active";
+      goto error;
+   }
+
    /*
     * This is very important: this is the only way to signal the existence of
     * this guest application to VMware.