Error: corrupt atom table using 1.19.3/OTP28 vs 27

Questions / Help
1

I’ve just updated an escript based application of mine from Elixir 1.17 to 1.19.

At the same time I attempted to update from OTP 27.2.2 to 28.1.1

After switching to 1.19.3-otp28, nuking the _build folder, and recompiling, the escript binary gives the following error:

=ERROR REPORT==== 20-Nov-2025::14:32:27.189484 ===
beam/beam_load.c(150): Error loading module rez_escript:
  corrupt atom table


escript: exception error: undefined function rez_escript:main/1
  in function  escript:run/2 (escript.erl, line 904)
  in call from escript:start/1 (escript.erl, line 418)
  in call from init:start_it/1
  in call from init:start_em/1
  in call from init:do_boot/3

Going back to 1.19.3-otp27 with 27.3.4.6 and the escript binary works fine.

I couldn’t find anything much sensible via Google and errors in beam_load.c is a bit above my pay grade so I thought I would report it here.

1 Like
2

Never seen that, very interesting.

IMO you should make a small reproducible app and report this to the Erlang team on ErlangForums. They would be interested, I think.

3

Did you nuke deps too? Bc I’ve been switching between 1.18 and 1.19, I recently found a succinct way to delete it all from orbit: mix clean --deps

Edit: Right, _build contains the compiled deps, sorry. I got wires crossed because I had been using ‘mix clean’ and had run into issues with deps on the wrong Elixir version.

1 Like
4

I’ve been nuking the _build folder.

5

searching for the error message I found this commit-message:

This commit changes the atom table in BEAM files to use a variable
length encoding for the length of each atom. For atoms up to 15 bytes,
the length is encoded in one byte. The header for the atom table is
also changed to indicate that new encoding of lengths are used.
Attempting to load a BEAM file compiled with Erlang/OTP 28 in
Erlang/OTP 27 or earlier will result in the following error message:

    1> l(t).
    =ERROR REPORT==== 8-Oct-2024::08:49:01.750424 ===
    beam/beam_load.c(150): Error loading module t:
      corrupt atom table

    {error,badfile}

so maybe an old runtime (27) is used for running the escript? :thinking:

1 Like
6

Hi @mattmower, did you recompile the escript (mix escript.build)? This error seems like the kind of error that comes about when using BEAM code from a later OTP on an older OTP. I realize you’re going the other way, but still it makes me think this is a similar incompatibility. I’m not sure exactly how escript is expected to handle BEAM code versioning.

1 Like
7

I have an install script that does the escript.build and moves the binary into the right place so I think so but of course I can’t be entirely certain that I didn’t good somehow.

8

Is it possible that wherever you’ve copied the escript to, at the time of execution the system is still finding the prev version OTP binaries on the PATH?

9

That I don’t believe is likely, because I was running & re-running as I was trying different versions of Elixir & OTP.

10

This will happen if you compile a escript for Erlang/OTP 28 and then attempt to run it on Erlang/OTP 27 and earlier.

4 Likes
11

Ah, I think this reveals a misunderstanding that I have about escript.

When the docs said “This task guarantees the project and its dependencies are compiled and packages them inside an escript.” I mistakenly thought that included the OTP runtime.

So my problem is that I am compiling the escript against OTP28 but, when using the binary (outside the asdf folder where the binary is built) it’s finding the OTP27 runtime?

12

escripts do not include otp. They expect the system running the escript to have an the otp installation.

2 Likes
13

Yep okay the solution was to put a matching asdf config where I am using the escript binary. I don’t think this complicates my burrito distribution as that will include the matching OTP.

Thanks @josevalim and @LostKobrakai .

2 Likes