On Wed, Jul 06, 2016 at 09:56:10AM -0700, Philip Guenther wrote: > On Wed, 6 Jul 2016, Tobias Ulmer wrote: > > On Tue, Jul 05, 2016 at 07:01:11PM +0100, Dimitris Papastamos wrote: > > > On Tue, Jul 05, 2016 at 02:14:57PM +0200, Martin Pieuchot wrote: > > > > Without more information it's hard to find what could be the reason > > > > for this crash. Being able to reproduce the crash easily is the key > > > > to debugging. Can you do that? > > > > > > while :; do (chrome &); sleep 8; pkill chrome; done > > > > > > It takes up to a minute to trigger it. I should mention however since > > > I just noticed (sorry about this) that I am running with your scheduler > > > hack from some months ago. > > > > Unrelated. I've run into the same issue with normals snaps. Third time > > crashing on shutdown now. Chrome exit seems to be a likely trigger. > > Sure, but if the yield diff makes it more likely to trigger and reduces > the frustration of those trying to track it down, then that's a Good > Thing. I left a box in a loop for hours building stuff and starting and > killing chrome and firefox and didn't hit it...even though I've hit it at > boot, when starting chrome, and at semi-random other times. I'm going to > throw the yield patch onto the box and try again...
On top of the yield patch, also try Otto's malloc diff[0] as well. With that I can trigger it in 10-20 seconds. [0] http://www.drijf.net/openbsd/malloc/malloc-20160511.diff
