Fixed an issue with the connectivity stack which does not change

"lasttop" after a new heap has been allocated and "top" is reset.
This is a minor issue, as even random data at the top of the
newly allocated heap is vanishingly unlikely to make a match,
but valgrind caught it as a use of unallocated memory, and it
should be fixed.

VERSION

@@ -1 +1 @@
-8.3.655
+8.3.656

database/DBconnect.c

@@ -1037,7 +1037,13 @@ dbcConnectFunc(tile, dinfo, cx)
     if (++csa2->csa2_top == CSA2_LIST_SIZE)
     {
 	/* Reached list size limit---need to push the list and	*/
-	/* start a new one.					*/
+	/* start a new one.  NOTE:  Setting lasttop to -1 means	*/
+	/* that some entries may be duplicated between the	*/
+	/* stacks, which is a small inefficiency.  In theory,	*/
+	/* lasttop could be left as is, then if lasttop > top	*/
+	/* when searching the last 5 entries, pop the stack, do	*/
+	/* the search, and then push the stack again.  But it's	*/
+	/* a lot easier just to be slightly inefficient.	*/
 
 	conSrArea *newlist;
 
@@ -1045,6 +1051,7 @@ dbcConnectFunc(tile, dinfo, cx)
 	StackPush((ClientData)csa2->csa2_list, csa2->csa2_stack);
 	csa2->csa2_list = newlist;
 	csa2->csa2_top = 0;
+	csa2->csa2_lasttop = -1;
     }
 
     csa2->csa2_list[csa2->csa2_top].area = newarea;

resis/ResJunct.c

@@ -69,6 +69,7 @@ ResNewTermDevice(tile, tp, n, xj, yj, direction, PendingList)
 
     ri = (resInfo *) TiGetClientPTR(tp);
     resDev = ri->deviceList;
+    if (resDev == NULL) return;			/* Shouldn't happen? */
     if ((((ri->sourceEdge & direction) != 0) && (resDev->rd_nterms == 4))
 		|| (resDev->rd_nterms > 2))
     {