Random assert on "Resuming fiber that is not on HOLD" libasync

[Positronic]

Running a fairly simple WebInterface that accepts POSTs with some text, does some file IO and process IO (using std.file and std.process), then responds with res.writeJsonBody().
I can send several request-reply (maybe about 10) before the crash randomly manifests.

However, the stack trace below appears to be mostly inside vibe.core, so I'm not sure if or where my code is the problem. Should I be using some vibe.d equivalent of std.file and std.process to prevent an incompatibility with Phobos? If not, then maybe there is an issue with the libasync driver?

core.exception.AssertError@..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\core.d(1098): Resuming fiber that is not on HOLD.
----------------
0x00007FF60826732C in d_assert_msg
0x00007FF60803093E in vibe.core.core.VibeDriverCore.yieldAndResumeTask at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\core.d(1100)
0x00007FF608034A7B in vibe.core.drivers.libasync.LibasyncDriver.processTimers.__lambda1 at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\drivers\libasync.d(366)
0x00007FF60800B91D in vibe.core.drivers.timerqueue.TimerQueue!(vibe.core.drivers.libasync.TimerInfo, 10000L).TimerQueue.consumeTimeouts at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\drivers\timerqueue.d(107)
0x00007FF6080347CA in vibe.core.drivers.libasync.LibasyncDriver.processTimers at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\drivers\libasync.d(356)
0x00007FF608034D5E in vibe.core.drivers.libasync.LibasyncDriver.rescheduleTimerEvent at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\drivers\libasync.d(384)
0x00007FF608034171 in vibe.core.drivers.libasync.LibasyncDriver.rearmTimer at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\drivers\libasync.d(316)
0x00007FF60807D995 in vibe.core.drivers.libasync.LibasyncTCPConnection.waitForData at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\drivers\libasync.d(1100)
0x00007FF6080C9BC7 in vibe.http.server.handleHTTPConnection at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\http\server.d(1487)
0x00007FF608078049 in vibe.http.server.listenHTTPPlain.doListen.__lambda3 at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\http\server.d(1376)
0x00007FF608080376 in vibe.core.drivers.libasync.LibasyncTCPConnection.onConnect at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\drivers\libasync.d(1343)
0x00007FF608093042 in vibe.core.core.makeTaskFuncInfo!(void delegate(), ).makeTaskFuncInfo.callDelegate at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\core.d(468)
0x00007FF607FE7F4B in vibe.core.core.CoreTask.run at C:\Projects\webDSandbox\..\..\Users\dougn\AppData\Roaming\dub\packages\vibe-d-0.7.25\source\vibe\core\core.d(969)
0x00007FF60826D9F8 in void core.thread.Fiber.run()
0x00007FF60829D8E1 in fiber_entryPoint
0x00007FF60826DF59 in D4core6thread5Fiber9initStackMFNbZ10trampolineFZv
Task terminated with unhandled exception: Resuming fiber that is not on HOLD.

...then the stack trace repeats again, but without the last line.

[s-ludwig]

Can you try with the latest 0.7.26 beta version (dub upgrade --prerelease)? The issue should be fixed there if I remember correnctly.

[Positronic]

Whoa - that was fast! I was going to append my build info, library versions, etc. but I was too slow. FYI, I did dub upgrade for memutils 0.4.1 -> 0.4.2 and it still happens.

Sure, I'll try the 0.7.26-beta.1 .....
Perfect! It seems to work now. I cleaned, upgraded with --prerelease, done about 100 request-reply, and can't reproduce it! Thanks - I think this issue can be closed.

[s-ludwig]

Corresponding PR, for reference: #1204