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
- Same as the detailed variant: ensure a consistent, clean Garnet build.
- Inspect the Lua state's stack depth/type at the point of failure (add diagnostics) to recover a cause.
- 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
- Treat any 'Could not initialize Lua VM' as a fatal build/deploy inconsistency and fail the session/startup.
- Avoid reusing a LuaRunner after a prior initialization error; create a fresh state.
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
- Could not initialize Lua VM: {innerError}
- Could not initialize Lua sandbox state: {errMsg}
- {errStr}
- Internal Lua Error: {res}
- Could not run function preamble: {errMsg}
AI-assisted analysis of microsoft/garnet@951b0fc683 (2026-08-13).
Data as JSON: /api/errors/33fa9b8c5d9d8d2f.
Report an issue: GitHub.