libuv: Assertion failed: new_time >= loop->time
- Version: 1.16.1
- Platform: Windows 7 64 Bit
Using latest node.js (libuv version 1.16.1) on my machine, causes the following error:
Assertion failed: new_time >= loop->time, file src\win\timer.c, line 37
I’m using a non overclocked AMD FX-6300. Yesterday it worked fine, but after a reboot it does not work anymore.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 126 (26 by maintainers)
Links to this issue
Commits related to this issue
- win: work around QueryPerformanceCounter() turning backwards This is not a great solution to the referenced bug, but it seems fair as libuv is intended to be a platform abstraction library that (also... — committed to addaleax/libuv by addaleax 4 years ago
- win, util: rearrange uv_hrtime Rearrange math operations in uv_hrtime. This is a workaround for a probable compiler bug in VS2019. Fixes: https://github.com/libuv/libuv/issues/1633 — committed to JaneaSystems/libuv by bzoz 4 years ago
- win, util: rearrange uv_hrtime Rearrange math operations in uv_hrtime. This is a workaround for a probable compiler bug in VS2019. Fixes: https://github.com/libuv/libuv/issues/1633 PR-URL: https://... — committed to JeffroMF/libuv by bzoz 4 years ago
can also reproduce it with Surface Pro 7 i7-1065G7 when working with firebase
I’ve reported this issue on Windows Feedback Hub: https://aka.ms/AA7ujea
I have this error on a newly set up xps 13 2 in 1 with ice lake chip with windows 10. I tried restarting multiple times, but it didn’t help. The clock is off by 1 second compared to https://www.timeanddate.com/ and it should be the correct UTC time. What’s even weirder, when I run the tool in WSL on the very same machine, it works and doesn’t complain.
WSL is a good workaround, but it would be nice if it were also working directly in windows. Any ideas?
Look like the fix works. Do we have any plan to cherry-pick the fix to LTS versions of NodeJS?
For commenters: Currently the best thing to do is probably to wait for 15.0 where it’s fixed.
It works 👍
Having same issue on Surface Pro 7 with latest driver and firmware updates. This issue definitely should be reopened.
Thanks @bzoz and @saschanaz for following through with this and iterating on this so fast!
Well now this is embarrassing:
Assertion failed: scale != 0, file C:\Users\Kagami\Documents\GitHub\node\deps\uv\src\win\util.c, line 473I have a Lenovo Yoga C940 with same i7-1065G7 and i got same error. Is there a fix available?
Hi guys, I was seeing the same error on my XPS 2in1 same spec as @Yonom . Upon changing to a desktop machine I started to see this other error: ERR_HTTP_HEADERS_SENT(‘set’); This stack overflow thread suggested the following: That particular error occurs whenever you try to send more than one response to the same request and is usually caused by improper asynchronous code.
So I went back to the code where I was doing this: `router.get(‘/’, (req, res) => {
}); `
Now the answer for me was obvious, I was calling render twice in my API endpoint! After removing the second call, all worked perfectly.
Upgrading Node version to 16 fixed the error for me as well.
I upgraded NODEJS to the version 12.22.10 and I don’t see this issue anymore.
It is not working on Intel ice lake CPUs.
did you try my suggestion above (synchronizing the clock)?
@saschanaz I’ll do that in the public issue tracker: https://developercommunity.visualstudio.com/spaces/8/index.html
Could you test if this branch reproduces: https://github.com/bzoz/node/tree/vsbug-repro? It is current v14.x Node with added
assert(scale != 0);. Just to make sure we did not mess something up in the meantime. Also, can you check if you are running the latest VS2019?Yay!
Can you test this one: https://github.com/bzoz/node/commit/710e1f6b6db681a1771cad1999b5fba53174c90b, its all those commits squashed and rebased onto current Node master. If that works, I’ll open a PR.
Hm… I’ll try to rearrange some bits, I’ll let you know when it is done.
BTW, thanks a lot!
I’m running into the same issue as others in this thread, and like some others I’m using a new Dell XPS 13 2-in-1 9300 with the i7-1065G7 CPU.
After a quick reboot into the BIOS, it appears that my machine is running BIOS version
1.0.6. A newer version,1.0.7, was released on 2020-04-06. Unfortunately for me, my laptop is a work laptop and I don’t have privileges to apply BIOS updates, so I can’t test if this version will fix the problem or not (and due to current global events I’m not exactly in the office much these days). The release notes mention “microcode updates” which is not really specific enough to know if this can fix the issue or not.Is there anyone else on this thread that has a Dell XPS 13 9300 with this CPU and that is comfortable installing BIOS updates that would be willing to try this update on the behalf of the rest of us?
Not so far. Please do “Add similar feedback” for them to notice.
Right.
@soraryu I haven’t, because I don’t have an affected system. You have, so you should.
@saschanaz Unfortunately, no. I don’t know anyone at Intel you could reach out directly to either.
I’d log a support issue through the regular channels. Someone at MS or Intel will take notice when enough people do.
@bnoordhuis can you or someone else please reopen this issue. It is still ongoing and preventing entire categories of devices from working correctly.
Quick update, on my Surface Pro 7, I moved over to WSL v1 about a month ago and haven’t seen the issue since (fingers crossed)… Might be an option?
Yes, Surface Laptop 3, i7-1065G7 and Windows 10. Still getting the issue.
Tried latest firmware, upgrading node to 12.6.3, no luck so far.
@suavelizard could you share a link to this update? I have the latest Surface Pro 7 firmware installed, and still experience this issue. There are no updates in Intel website either (https://downloadcenter.intel.com/product/196597/intel-core-i7-1065g7-processor-8m-cache-up-to-3-90-ghz)
@Jan-Kruse You might also want to check your onboard CMOS backup battery