At its core the BEAM is a preemptive multi-threaded system. So if the clock is funky then the scheduling will not be fair. If the clock warp too much then I guess some GenServer calls could even timeout.
derek-zhou
itopiz
I am having the same issue.
My environment:
- Host
- Windows 11 Pro 24H2
- VirtualBox 7.1.4
- Guest
- NixOS 24.11.20250116.3355599 (Vicuna)
- Linux version 6.6.71
- Elixir 1.14.5 and Erlang/OTP 25 [erts-13.2.2.11]
I also tested on different VM environments (VMware Workstation 15 Pro, Proxmox) and never experienced this issue.
For reference, the issue happens even with all of the following conditions combined:
- Disabled the Guest Additions Time Synchronization
- Disabled Guest Additions, for good measure
- Disabled NTP synchronization
- Time Correction enabled with Time Warp Mode set to either No Time Warp Mode or Multi-Time Warp Mode
I enabled all the logs that I could, I cannot understand what causes this issue. For info:
Feb 19 10:42:43 fas myapp[1292]: OS monotonic time stepped backwards!
Feb 19 10:42:43 fas myapp[1292]: Previous time: 417898883425
Feb 19 10:42:43 fas myapp[1292]: Current time: 417898880929
Feb 19 10:42:43 fas systemd-coredump[1570]: Process 1292 (beam.smp) of user 399 terminated abnormally with signal 6/ABRT, processing...
Feb 19 10:42:43 fas systemd[1]: Created slice Slice /system/systemd-coredump.
Feb 19 10:42:43 fas systemd[1]: Started Process Core Dump (PID 1570/UID 0).
Feb 19 10:42:43 fas systemd-coredump[1571]: Removed old coredump core.beam\x2esmp.399.5f2f98555c0e485c811ad1241bae2bc8.3653.1739957532000000.zst.
Feb 19 10:42:43 fas systemd-coredump[1571]: Removed old coredump core.beam\x2esmp.399.5f2f98555c0e485c811ad1241bae2bc8.3903.1739957641000000.zst.
Feb 19 10:42:48 fas systemd-coredump[1571]: Process 1292 (beam.smp) of user 399 dumped core.
Module crypto_callback.so without build-id.
Module crypto.so without build-id.
Module argon2_nif.so without build-id.
Module asn1rt_nif.so without build-id.
Module dyntrace.so without build-id.
Module libgcc_s.so.1 without build-id.
Module libstdc++.so.6 without build-id.
Module libz.so.1 without build-id.
Module libncursesw.so.6 without build-id.
Module beam.smp without build-id.
Stack trace of thread 1330:
#0 0x00007fa6e969aa9c __pthread_kill_implementation (libc.so.6 + 0x92a9c)
#1 0x00007fa6e9648576 raise (libc.so.6 + 0x40576)
#2 0x00007fa6e9630935 abort (libc.so.6 + 0x28935)
#3 0x0000000000455349 erts_exit_epilogue.cold (beam.smp + 0x55349)
#4 0x0000000000539953 erts_exit_vv (beam.smp + 0x139953)
#5 0x0000000000539aaf erts_exit (beam.smp + 0x139aaf)
#6 0x00000000005ce0fe get_os_drift_corrected_time (beam.smp + 0x1ce0fe)
#7 0x00000000005d0b39 erts_get_monotonic_time (beam.smp + 0x1d0b39)
#8 0x0000000000460e40 scheduler_wait (beam.smp + 0x60e40)
#9 0x0000000000470cf9 erts_schedule (beam.smp + 0x70cf9)
#10 0x00007fa6a72445ad n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
Feb 19 10:42:48 fas systemd[1]: systemd-coredump@0-1570-0.service: Deactivated successfully.
Feb 19 10:42:48 fas systemd[1]: systemd-coredump@0-1570-0.service: Consumed 1.970s CPU time, 5M memory peak, 1000K read from disk.
Feb 19 10:42:48 fas systemd[1]: myapp.service: Main process exited, code=dumped, status=6/ABRT
Feb 19 10:42:48 fas systemd[1]: myapp.service: Failed with result 'core-dump'.
Feb 19 10:42:48 fas systemd[1]: myapp.service: Scheduled restart job, restart counter is at 1.
Feb 19 10:42:48 fas systemd[1]: Starting MyApp...
Considering the clear warning in the Erlang documentation (see below), I do not believe disabling time correction (i.e. +c false) is a solution.
Time correction
[…]
You typically never want to disable time correction. Previously a performance penalty was associated with time correction, but nowadays it is usually the other way around. If time correction is disabled, you probably get
bad scalability, bad performance, and bad time measurements.
Does anyone have more information on this? Has anyone reported this to Erlang and/or VirtualBox?
0
itopiz
itopiz
I reported the issue to the Erlang project: Elixir apps running on VirtualBox crash repetitively with `OS monotonic time stepped backwards!` · Issue #9479 · erlang/otp · GitHub
0
tcoopman
The issue is that your VM turned back in time, which erlang doesn’t like.
After reading a bit more on this, I also found this which says disabling time correction is the solution: Passing erl options to erlc? - #7 by rickard - Questions / Help - Erlang Programming Language Forum - Erlang Forums
Reading the time and correction module in Erlang was not entirely clear, but I think all the time warping is about the erlang monotonic time and not the OS monotonic time.
3
itopiz
Issue reported on VirtualBox Forums: Erlang crashes due to: OS monotonic time stepped backwards! - virtualbox.org
2
itopiz
Issue also reported on the VirtualBox bug tracker: #22334 (VM clock goes backwards => fixed in svn) – Oracle VirtualBox
1
itopiz
This was indeed an issue with VirtualBox and it has been fixed (#22334 (VM clock goes backwards => fixed in svn) – Oracle VirtualBox). Waiting for a new VirtualBox release now.
5
dfalling
Thank you for reporting this to them! I should have done that when I first hit this to save us all some grief.
0
itopiz
VirtualBox 7.1.8 has been released on April 15 2025 and fixes the issue:
0