fix off-by-one in dump_childnos()

Fixes a segfault:

## pids: (60 active)
0-7: 0 0 0 0 0 0 0 0
8-15: 0 0 0 0 0 0 0 0
16-23: 0 0 0 0 0 0 0 0
24-31: 0 0 0 0 0 0 0 0
32-39: 0 11081 11082 11083 11084 11085 11086 11087 40-47: 11088 11089 11090 11091 11093 11094 11095 11096 48-55: 11097 11098 11099 11100 11101 11102 0 0 Segmentation fault

---
 pids.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 8b77e2f..1a23284 100644
@@ -82,7 +82,7 @@ void dump_childnos(void)
 		for (j = 0; j < 8; j++) {
 			struct childdata *child;
 
-			if (i + j > max_children)
+			if (i + j >= max_children)
 				break;
 
 			child = shm->children[i + j];

2.9.3

Applied. If you're seeing that though, that's indicative of a bigger problem (that we corrupted the pid table, or lost track of a child proc.). I've not seen that happen in about a year, does it happen often for you?

Dave

2017-04-16 21:34 GMT+03:00 Dave Jones <[email protected]>:

Yea, I believe it was just about to exit anyways after the debug output.

I was testing trinity in some minimal busybox & qemu environment, and saw it a few times.
Now that I try it again, cannot reproduce the segfault anymore...

All the trinity processes have read-write access to the pids[] array? So any one of them could corrupt the memory...?

-Tommi