Fix potential memory leak on GopherStateData constructor errors

In the unusual event that the GopherStateData object constructor fails
it is possible that the destructor gets called without having gone
through the deleteThis() and swangSong() dance. Since the constructor
allocates memory buffer we need to clean that up.

 Detected by Coverity Scan. Issue 1318022

diff --git a/src/gopher.cc b/src/gopher.cc
index 3dcaf9cb8a8cd5759cfac0baafcdd5b5489eeebd..e151f928a65df2474c15084f9c61a03898f2b5a7 100644 (file)
--- a/src/gopher.cc
+++ b/src/gopher.cc
@@ -97,6 +97,7 @@ public:
         entry->lock("gopherState");
         *replybuf = 0;
     }
+    ~GopherStateData() {if(buf) swanSong();}
 
     /* AsyncJob API emulated */
     void deleteThis(const char *aReason);
@@ -166,8 +167,10 @@ GopherStateData::swanSong()
     if (entry)
         entry->unlock("gopherState");
 
-    if (buf)
+    if (buf) {
         memFree(buf, MEM_4K_BUF);
+        buf = nullptr;
+    }
 }
 
 /**