From: VMware, Inc <>
Date: Mon, 21 Nov 2011 22:48:42 +0000 (-0800)
Subject: Avoid passing NULL channel to message library.
X-Git-Tag: 2011.11.20-535097~85
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f58c3680552a252244cdfff053afe24791a03cb7;p=thirdparty%2Fopen-vm-tools.git

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 25d9251e9..23e2569b4 100644
--- 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.