Passing erl options to erlc?

Questions / Help
,
1

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.

1 Like
2

env ERL_FLAGS="+C no_time_warp" erlc

2 Likes
3

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

ERL_AFLAGS="+C no_time_warp" erlc some_file.erl
1 Like
4

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

1 Like
5

Hi again,

After reading Erlang -- Time and Time Correction in Erlang, 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.

6

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.

7

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.

2 Likes
8

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.

9

Well, Rickard is who helped you :slight_smile:

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.

10

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)

1 Like
11

Ahh, I see, I missed that :slight_smile:

Thank you for sharing that! It may help others in the future :wink:

12

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.

13

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.

1 Like