# Passing erl options to erlc?

**URL:** <https://erlangforums.com/t/passing-erl-options-to-erlc/3045>\
**Category:** Questions / Help\
**Tags:** time, vm\
**Created:** [November 21, 2023, 2:31pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045 "2023-11-21T14:31:02Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Wondersye](https://erlangforums.com/letter_avatar_proxy/v4/letter/w/f14d63/32.png) [@Wondersye](https://erlangforums.com/u/Wondersye)\
**Post date:** [November 21, 2023, 2:31pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/1 "2023-11-21T14:31:02Z")

</div>

Hi,

On some virtualized machines (possibly a bit exotic), some Erlang programs were aborting due to the following problem: “Monotonic time stepped backwards!”.

Adding the “+C no\_time\_warp” flag apparently solved the problem for these programs, yet their compilation was also affected by the very same problem (erlc then aborting).

In addition to erl, is there a way of specifying the aforementioned option to erlc? (just specifying that option as it is results in “bad term: C” - as it could be anticipated by reading erlc’s documentation)

Thanks in advance for any hint,  
Best regards,

Olivier.

---

<div class="post-metadata">

**Author:** ![Led](https://erlangforums.com/user_avatar/erlangforums.com/led/32/1594_2.png) [@Led](https://erlangforums.com/u/Led)\
**Post date:** [November 21, 2023, 2:55pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/2 "2023-11-21T14:55:24Z")

</div>

`env ERL_FLAGS="+C no_time_warp" erlc`

---

<div class="post-metadata">

**Author:** ![bjorng](https://erlangforums.com/user_avatar/erlangforums.com/bjorng/32/174_2.png) [@bjorng](https://erlangforums.com/u/bjorng)\
**Post date:** [November 21, 2023, 2:55pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/3 "2023-11-21T14:55:36Z")

</div>

> [@Wondersye](#):
>
> In addition to erl, is there a way of specifying the aforementioned option to erlc? (just specifying that option as it is results in “bad term: C” - as it could be anticipated by reading erlc’s documentation)

You can pass options to `erl` via the environment variable `ERL_AFLAGS`. For example:

```erlang
ERL_AFLAGS="+C no_time_warp" erlc some_file.erl

```

---

<div class="post-metadata">

**Author:** ![Wondersye](https://erlangforums.com/letter_avatar_proxy/v4/letter/w/f14d63/32.png) [@Wondersye](https://erlangforums.com/u/Wondersye)\
**Post date:** [November 21, 2023, 6:55pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/4 "2023-11-21T18:55:53Z")

</div>

Thanks Led and Björn for these information!  
Best regards,  
Olivier.

---

<div class="post-metadata">

**Author:** ![Olivier](https://erlangforums.com/letter_avatar_proxy/v4/letter/o/d2c977/32.png) [@Olivier](https://erlangforums.com/u/Olivier)\
**Post date:** [November 23, 2023, 2:30pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/5 "2023-11-23T14:30:50Z")

</div>

Hi again,

After reading [Erlang -- Time and Time Correction in Erlang](https://www.erlang.org/doc/apps/erts/time_correction#time-warp-safe-code), I thought that the “+C no\_time\_warp” option could ensure (possibly at the risk of freezing a bit) that the Erlang VM time remained silently monotonic, despite the OS one going possibly backwards at times; nevertheless (and after having double-checked) a command-line like (with Erlang/OTP 26/erts-14.1):

$ XXX/bin/erl -eval ‘yyy:run()’ +W w -pz A\_LONG\_SERIES\_OF\_PATHS -smp +K true +A 128 +zdbbl 1048576 +P 1000000 -setcookie zzzz -kernel inet\_dist\_listen\_min 50000 inet\_dist\_listen\_max 55000 +pc unicode -noinput +C no\_time\_warp -extra --uuu PATH vvv --batch

may apparently still trigger (after a while):

Monotonic time stepped backwards!  
Previous time: 1806968038  
Current time: 1806967880  
Aborted

(I could check that erlang:system\_info(time\_warp\_mode) returned ‘no\_time\_warp’ indeed)

I was wondering whether it was among the expected behaviours and if there was a way of avoiding this problem as a whole (even if necessary by sacrificing the performances - for us it is just for the sake of a demo; we just want it to continue instead of crashing).

Thanks in advance for any hint!

Best regards,

Olivier.

---

<div class="post-metadata">

**Author:** ![starbelly](https://erlangforums.com/user_avatar/erlangforums.com/starbelly/32/209_2.png) [@starbelly](https://erlangforums.com/u/starbelly)\
**Post date:** [November 23, 2023, 6:52pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/6 "2023-11-23T18:52:21Z")

</div>

Can you tell us what major version of Erlang/OTP you are using? Also, it would be good to know about the exotic setup a bit.

---

<div class="post-metadata">

**Author:** ![rickard](https://erlangforums.com/user_avatar/erlangforums.com/rickard/32/184_2.png) [@rickard](https://erlangforums.com/u/rickard)\
**Post date:** [November 23, 2023, 9:17pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/7 "2023-11-23T21:17:38Z")

</div>

The runtime system aborts with `Monotonic time stepped backwards!` if it detects that the operating system’s monotonic time stepped backwards which should never happen. If it does, the clock is broken and cannot be used for time correction. If you disable time correction (`+c false`), it wont use OS monotonic time and should not abort this way. You can read more about how this effects time in the runtime system [here](https://www.erlang.org/doc/apps/erts/time_correction#time-correction).

---

<div class="post-metadata">

**Author:** ![Wondersye](https://erlangforums.com/letter_avatar_proxy/v4/letter/w/f14d63/32.png) [@Wondersye](https://erlangforums.com/u/Wondersye)\
**Post date:** [November 25, 2023, 9:41am UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/8 "2023-11-25T09:41:21Z")

</div>

Thanks Bryan and Rickard; I think I figured out how this could happen: our user node spawns and connects to a (here: single, local) computing node, and I guess the monotonic problem was finally happening only in the latter one, to which the non-timewarping option had not been propagated; the time error must have been forwarded to the user node (I imagine thanks to some group\_leader related mechanism), which was reporting it. At least that is what I imagine is happening.

Many thanks for your answers! Olivier.

---

<div class="post-metadata">

**Author:** ![starbelly](https://erlangforums.com/user_avatar/erlangforums.com/starbelly/32/209_2.png) [@starbelly](https://erlangforums.com/u/starbelly)\
**Post date:** [November 25, 2023, 6:38pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/9 "2023-11-25T18:38:34Z")

</div>

Well, Rickard is who helped you 🙂

That said, the reason I asked what OTP version you were using is that applying `no_time_warp` might be something of a noop if you’re running Erlang/OTP \< 26 then `no_time_warp` is the default anyway and you are probably just lucking out. If you really want to avoid a crash in a demo then you ought to follow Rickards advice and disable time correction all together, until such time you can figure out why os monotonic on your VM is jumping backwards, which as Rickard stated should never happen.

---

<div class="post-metadata">

**Author:** ![Wondersye](https://erlangforums.com/letter_avatar_proxy/v4/letter/w/f14d63/32.png) [@Wondersye](https://erlangforums.com/u/Wondersye)\
**Post date:** [November 26, 2023, 1:01pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/10 "2023-11-26T13:01:30Z")

</div>

Hi Bryan,  
Actually I had specified (through my secondary, work-related, forum account) that it was Erlang/OTP 26/erts-14.1 (that is 26.1; I prefer sticking to the latest stable version).  
For the sake of this demo, our application is running on a Debian 12 (Bookworm) virtualised (thanks to VirtualBox I imagine) on top of a Windows host (of course we would have preferred a more suitable setting), and apparently this combination may result in non-monotonic time.  
I anticipate that a `no_time_warp` option - this time applied to _all_ nodes involved - will suffice; otherwise, as Rickard mentioned, disabling time correction (`+c false`) will still be an option.  
Time will tell! (pun intended)

---

<div class="post-metadata">

**Author:** ![starbelly](https://erlangforums.com/user_avatar/erlangforums.com/starbelly/32/209_2.png) [@starbelly](https://erlangforums.com/u/starbelly)\
**Post date:** [November 26, 2023, 5:32pm UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/11 "2023-11-26T17:32:45Z")

</div>

> [@Wondersye](#):
>
> Actually I had specified (through my secondary, work-related, forum account) that it was Erlang/OTP 26/erts-14.1 (that is 26.1; I prefer sticking to the latest stable version).

Ahh, I see, I missed that 🙂

> [@Wondersye](#):
>
> For the sake of this demo, our application is running on a Debian 12 (Bookworm) virtualised (thanks to VirtualBox I imagine) on top of a Windows host (of course we would have preferred a more suitable setting), and apparently this combination may result in non-monotonic time.

Thank you for sharing that! It may help others in the **future** 😉

---

<div class="post-metadata">

**Author:** ![jimdigriz](https://erlangforums.com/user_avatar/erlangforums.com/jimdigriz/32/1885_2.png) [@jimdigriz](https://erlangforums.com/u/jimdigriz)\
**Post date:** [November 27, 2023, 8:06am UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/12 "2023-11-27T08:06:50Z")

</div>

If this regularly affects you and your service is not CPU bound could you do an experiment and pin the guest to a single physical CPU on your host?

You should be able to do this by using `taskset` on the host.

---

<div class="post-metadata">

**Author:** ![Wondersye](https://erlangforums.com/letter_avatar_proxy/v4/letter/w/f14d63/32.png) [@Wondersye](https://erlangforums.com/u/Wondersye)\
**Post date:** [November 27, 2023, 10:34am UTC](https://erlangforums.com/t/passing-erl-options-to-erlc/3045/13 "2023-11-27T10:34:04Z")

</div>

Hi Alexander,  
Thanks for your message. Actually it is just a one-off demonstration (for which performances do not matter that much), so I guess I will not investigate further, now that time-warping settings are propagating automatically from the user node to the spawned ones (to be tested soon in real conditions).  
The application is intensely concurrent but anyway meant to run on a proper platform (not virtualized - especially not on top of a Windows OS!).  
Best regards,  
Olivier.
