Ok managed to reproduce it on Linux by setting interval in config.h to 1ms and the patch fixes it. Thanks :)
Am Fr., 15. Feb. 2019 um 00:20 Uhr schrieb Michael Buch <[email protected]>: > > Ah I see, thanks for the example. Sorry, I overlooked your initial > email since it wasn't part of your patch mail. The patch seems fine > then, but I don't run OpenBSD at the moment and on the other platforms > this never occurred to me but perhaps someone who has encountered this > or can reproduce it with a trace can chime in. > > Thanks, > Michael > > Am Do., 14. Feb. 2019 um 23:41 Uhr schrieb Ingo Feinerer <[email protected]>: > > > > On Thu, Feb 14, 2019 at 09:16:23PM +0000, Michael Buch wrote: > > > Thanks for changing, on second thought though, I have my doubts about this > > > situation being possible. The cp times are millisecond increments since > > > boot and would only not increment from our perspective if we sampled at > > > submillisecond frequency. You can maximally > > > configure slstatus to 1ms so I dont think we need a check here > > > Did this happen to you? > > > > Yes, as I wrote in my initial explanatory mail > > (https://lists.suckless.org/hackers/1902/16697.html) this happens > > regularly (but not always) after a suspend and resume cycle on OpenBSD. > > This causes slstatus to crash. > >
