Page MenuHomePhabricator

Increased "Lua error: not enough memory" on some wikis since 1.47.0-wmf.18
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue:

It's also reported to affect eswiki and ptwiki.

A list of them can be found through searching:

What happens?:

Templates near the bottom of the page shows "Lua error: not enough memory." ("Lua错误:not enough memory。")

cl_timestamp shows a large influx of pages into the scribunto-common-error-category (Category:Pages with script errors), which coincides with the 1.47.0-wmf.18 train deployment to group2 wikis.

See:

What should have happened instead?:

Those pages did not have Lua memory issues a few days ago.

On-wiki discussions:

Software version: 1.47.0-wmf.18

Event Timeline

The HTML source of all these pages shows Lua memory usage: 52428xxx/52428800 bytes with the first number close to the maximum defined by the second number.

Also happening at the Spanish Wikipedia (example).

Requesting assistance in analyzing the issue, as the error message is unclear (only "Lua error: not enough memory"), and the problem starts occurring after rendering approximately 100 of the involved cite templates (Module: Citation CS1). It's rare for the Lua memory value to be so close to the limit.

Some abnormal and normal examples:

Bewfip renamed this task from Increased "Lua error: not enough memory" on zhwiki since 1.47.0-wmf.18 to Increased "Lua error: not enough memory" on some wikis since 1.47.0-wmf.18.Sep 5 2026, 9:04 AM
Bewfip updated the task description. (Show Details)
Bewfip added a subscriber: Chronus.

I noticed that the affected wikis' CS1 modules does not call require ('strict'), which was added for the canonical enwiki version in 2020. However, I suspect some GC issue may also play a role here.

Chronus triaged this task as High priority.Sep 6 2026, 12:12 AM

A temporary workaround:

This may effectively alleviate the "not_enough_memory" issue.

Thx @Bewfip for the reminder.

I purged the cache of all new entrants to the category on zhwiki. Almost all of the previous 532 pages' memory limit issue are gone. A few of those pages still hit the limit.

The problem persists on pt.wiki even after the change suggested by Shizao

Most functions in the zhwiki version had been local function. The ptwiki version would need more text replacements and testing to reduce the usage of global variables.

Change #1337599 had a related patch set uploaded (by Dondersmooi; author: Dondersmooi):

[mediawiki/extensions/Scribunto@master] Record the invocation frame per exported function instead of its env

https://gerrit.wikimedia.org/r/1337599

Change #1337600 had a related patch set uploaded (by Dondersmooi; author: Dondersmooi):

[mediawiki/extensions/Scribunto@master] Release exported-function metadata as soon as it is consumed

https://gerrit.wikimedia.org/r/1337600

In the common (non-shared) path mw.executeFunction() only needs the frame from that environment, and the frame is already known in executeModule(). There's no need to store the whole environment just to recover it later.

I've pushed the fix as two small, stacked patches:

  1. Record the frame, not the env — https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1337599
    • frameMap[func] = frame unconditionally (a single reference, not a _G clone).
    • envMap[func] = env / metatableMap[func] only when shareInvocationEnv is enabled — the only path that actually reuses the full environment.
    • mw.executeFunction() reads the frame straight from frameMap, falling back to getfenv() only for chunks that didn't come through executeModule().
  1. Release the metadata as soon as it's consumed — https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1337600
    • executeModule() records this metadata immediately before handing the function to the host, which runs it exactly once. So mw.executeFunction() now reads it into locals and clears the map entries before running user code, instead of relying on the weak-key (ephemeron) GC pass to drop them later. Under a hard memory limit, "set to nil now" vs. "GC will get to it eventually" can be the difference.

Can someone review these two patches?

A massive error in ruWikisource on the pages of encyclopedia glossaries (article lists). Examples: https://ru.wikisource.org/wiki/РСКД/Словник/A. https://ru.wikisource.org/wiki/Category:Страницы_с_ошибками_скриптов (Scribunto-common-error-category), there may be more errors in other places, categorization is still based on the old cache.

The problem is that we have a lot of templates in these encyclopedia lists that contain links to pages. The template itself uses only a basic parsing of the page title string (template 1, template 2), and then call a simple Lua local function with additional title parsing: https://ru.wikisource.org/wiki/Module:Header#L-878. I don't understand what could be causing the memory overload there; it's a single text string with ~50 characters long... This has worked fine for us for over a decade for huge encyclopedias...

Try cutting down the usage of global function definitions in that module. require ('strict') and Extension:TemplateSandbox can be handy when finding them.

Change #1339430 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/Scribunto@master] Revert Lua 5.4 support patches

https://gerrit.wikimedia.org/r/1339430

Change #1339441 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/extensions/Scribunto@wmf/1.47.0-wmf.19] Revert Lua 5.4 support patches

https://gerrit.wikimedia.org/r/1339441

Change #1339430 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@master] Revert Lua 5.4 support patches

https://gerrit.wikimedia.org/r/1339430

Change #1339441 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@wmf/1.47.0-wmf.19] Revert Lua 5.4 support patches

https://gerrit.wikimedia.org/r/1339441

Mentioned in SAL (#wikimedia-operations) [2026-09-11T05:15:54Z] <tstarling@deploy1003> Started scap sync-world: Backport for [[gerrit:1339441|Revert Lua 5.4 support patches (T437056)]]

Mentioned in SAL (#wikimedia-operations) [2026-09-11T05:20:18Z] <tstarling@deploy1003> tstarling: Backport for [[gerrit:1339441|Revert Lua 5.4 support patches (T437056)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-09-11T05:25:53Z] <tstarling@deploy1003> Finished scap sync-world: Backport for [[gerrit:1339441|Revert Lua 5.4 support patches (T437056)]] (duration: 09m 59s)

Mentioned in SAL (#wikimedia-operations) [2026-09-11T06:27:33Z] <TimStarling> for T437056: mwscript-k8s refreshLinks.php --wiki=eswiki --tracking-category scribunto-common-error-category

Mentioned in SAL (#wikimedia-operations) [2026-09-11T06:38:00Z] <TimStarling> also started refreshLinks for ptwiki and zhwiki, reparsing ~3000 pages altogether T437056

Mentioned in SAL (#wikimedia-operations) [2026-09-11T07:10:20Z] <TimStarling> killed jobs for T437056 since they weren't purging

Change #1339616 had a related patch set uploaded (by Arendpieter; author: Arendpieter):

[mediawiki/extensions/Scribunto@master] Take the invocation frame from frameMap in mw.executeFunction()

https://gerrit.wikimedia.org/r/1339616

Change #1337600 abandoned by Dondersmooi:

[mediawiki/extensions/Scribunto@master] Release exported-function metadata as soon as it is consumed

Reason:

Replaced by https://gerrit.wikimedia.org/r/1339616, rebuilt on top of the revert.

https://gerrit.wikimedia.org/r/1337600

Change #1337599 abandoned by Dondersmooi:

[mediawiki/extensions/Scribunto@master] Record the invocation frame per exported function instead of its env

Reason:

Replaced by https://gerrit.wikimedia.org/r/1339616, rebuilt on top of the revert.

https://gerrit.wikimedia.org/r/1337599

Bewfip closed this task as Resolved.EditedFri, Sep 11, 12:42 PM

Boldly closing this task, as the patch causing it was reverted.

Wikis affected by this can run bots that call API action=purge with forcelinkupdate: true set for those new entries in scribunto-common-error-category, or just wait some days for it to drain.
Note that the Action API at WMF currently has a 53s timeout (T410007), so don't pass too many titles in one call.

Change #1342603 had a related patch set uploaded (by Arendpieter; author: Arendpieter):

[mediawiki/extensions/JsonConfig@master] Use LuaModule::callFunction() when available

https://gerrit.wikimedia.org/r/1342603

Change #1342603 merged by jenkins-bot:

[mediawiki/extensions/JsonConfig@master] Use LuaModule::callFunction() when available

https://gerrit.wikimedia.org/r/1342603

Change #1339616 merged by jenkins-bot:

[mediawiki/extensions/Scribunto@master] Merge mw.executeModule() and mw.executeFunction()

https://gerrit.wikimedia.org/r/1339616

Change #1344137 had a related patch set uploaded (by Arendpieter; author: Arendpieter):

[mediawiki/extensions/JsonConfig@master] Drop the LuaEngine::executeModule() fallback

https://gerrit.wikimedia.org/r/1344137

Change #1344137 merged by jenkins-bot:

[mediawiki/extensions/JsonConfig@master] Drop the LuaEngine::executeModule() fallback

https://gerrit.wikimedia.org/r/1344137