Error: corrupt atom table using 1.19.3/OTP28 vs 27

mattmower

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.

12 comments

#erts

1 971 12

2025-11-24 20:50:01 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

dimitarvp

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.

Post #1

jerdew

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.

Post #2

mattmower

I’ve been nuking the _build folder.

Post #3

fizfaz

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

https://github.com/erlang/otp/commit/04b168dade6e798461893e32d8c59588a3e228fe

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?

Post #4

jstimps

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.

Post #5

mattmower

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.

Post #6

jstimps

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?

Post #7

mattmower

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

Post #8

josevalim

Creator of Elixir

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

Post #9

mattmower

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?

Post #10

Load more posts (2 remaining)