microsoft/garnet · critical · GarnetException

Could not initialize Lua VM

Error message

Could not initialize Lua VM

What it means

The same LoadBuffer failure path as the detailed variant, but the Lua stack did not contain a string error message (state.StackTop != 1 or state.Type(1) != LuaType.String), so Garnet cannot extract a cause. It is the fallback case: the sandbox failed to load but Lua provided no message.

Source

Thrown at libs/server/Lua/LuaRunner.cs:341

                ((byte)redisVersionParsed.Minor << 8) |
                ((byte)redisVersionParsed.Build << 0);
            state.PushInteger(redisVersionNum);
            if (!state.TrySetGlobal("garnet_REDIS_VERSION_NUM\0"u8))
            {
                throw new GarnetException("Insufficient space in Lua VM for redis version number global");
            }

            var loadRes = state.LoadBuffer(PrepareLoaderBlockBytes(allowedFunctions, logger).Span);
            if (loadRes != LuaStatus.OK)
            {
                if (state.StackTop == 1 && state.Type(1) == LuaType.String)
                {
                    state.KnownStringToBuffer(1, out var buff);
                    var innerError = Encoding.UTF8.GetString(buff);
                    throw new GarnetException($"Could not initialize Lua VM: {innerError}");
                }

                throw new GarnetException("Could not initialize Lua VM");
            }

            var sandboxRes = state.PCall(0, -1);
            if (sandboxRes != LuaStatus.OK)
            {
                string errMsg;
                try
                {
                    if (state.StackTop >= 1)
                    {
                        // We control the definition of LoaderBlock, so we know this is a string
                        state.KnownStringToBuffer(1, out var errSpan);
                        errMsg = Encoding.UTF8.GetString(errSpan);
                    }
                    else
                    {
                        errMsg = "No error provided";
                    }

View on GitHub (pinned to 951b0fc683)

Solutions

  1. Same as the detailed variant: ensure a consistent, clean Garnet build.
  2. Inspect the Lua state's stack depth/type at the point of failure (add diagnostics) to recover a cause.
  3. Rule out a corrupted or partially-initialized Lua state being reused.
Defensive patterns

Strategy: try-catch

Try / catch

catch (GarnetException ex) when (ex.Message == "Could not initialize Lua VM") {
    logger.LogCritical(ex, "Bare Lua init failure with no detail; rebuild/redeploy Garnet");
    throw;
}

Prevention

When it happens

Trigger: Identical construction path - state.LoadBuffer(PrepareLoaderBlockBytes(...)) returns non-OK - but the stack state does not match the (StackTop == 1 && Type(1) == String) shape, so no innerError is available.

Common situations: Same build/runtime mismatch as the detailed variant; also seen when the Lua state is left in an unexpected shape by a prior failed operation on the same runner.

Related errors


AI-assisted analysis of microsoft/garnet@951b0fc683 (2026-08-13). Data as JSON: /api/errors/33fa9b8c5d9d8d2f. Report an issue: GitHub.