2017-04-16 21:34 GMT+03:00 Dave Jones <davej@xxxxxxxxxxxxxxxxx>: > On Sun, Apr 16, 2017 at 09:29:14PM +0300, Tommi Rantala wrote: > > 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 > > 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.). Yea, I believe it was just about to exit anyways after the debug output. > I've not seen that happen in about a year, does it happen often for you? 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 -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
