Topic on Extension talk:Scribunto

Hello ! On a mediawiki installed on web host (https://www.ovhcloud.com/en-gb/web-hosting/professional-offer/ ) I have this error when i try to open Module or Template using modules.

this is my specs :

Produit	Version
MediaWiki	1.39.3
PHP	7.4.33 (fpm-fcgi)
MySQL	5.7.42-log
ICU	63.1
Lua	5.1.5

according to Extension:Scribunto :

• pcre: 10.35 2020-05-09 (>8.33)
• pcntl: no (but not "requirement removed in Scribunto for MediaWiki 1.29.")
• mbstring: yes
• `function_exists("proc_open")` on php file retruns `true`

• `$wgScribuntoDefaultEngine = 'luastandalone';` on LocalSettings.php

• I did `chmod 755 /path/to/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua` on ssh (because `uname -m` returns `x86_64`)

• `uname -r` returns `5.15.80-ovh-vps-grsec-zfs-classid`

does anyone have any idea where this might come from? Is it coming from the web hosting environment? How to test if Lua can be executed on the server? (I tried a simple "./lua" and it gives "segmentation fault")

@Marcellinjobard:

I tried a simple "./lua" and it gives "segmentation fault"

Well, that's probably a bad sign, as it should start an interactive lua session, displaying a > prompt and waiting for input. If it's crashing when you run it from a shell, there's a good chance it's crashing when PHP tries to run it too. But as to why it's crashing... tricky to say.

Some things you can try (assuming your current directory is .../extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/):

1. It's possible the crash is only in the interactive interpreter; perhaps it's having trouble accessing the terminal for some reason. In that case, executing a lua statement defined in the arguments might have a different outcome. Here's a simple one you can try:

   ./lua -e 'print(math.pi)'
   

   On my system that outputs 3.1415926535898.
2. If that also segfaults, and ldd is available in the environment, you can check what libraries the dynamic loader is resolving for the binary. But its dependencies are pretty minimal, and unlikely not to be met. On my Fedora 38 system:

   $ ldd ./lua
    linux-vdso.so.1 (0x00007ffced7d1000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f4bb40dd000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f4bb3c22000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f4bb4206000)
   

3. If gdb is available, you could run the binary in the debugger, so you'd at least get a stack trace when it segfaults. To do that, you'd:

   # Run the debugger and load the lua binary
   $ gdb ./lua
   # When you get a '(gdb)' prompt, gdb is waiting for debugger commands
   
   # First, run that same math.pi test
   (gdb) run -e 'print(math.pi)'
   
   # When the program segfaults and drops you back to the debugger again,
   # collect a stack trace
   (gdb) bt
   

Unfortunately, you won't have any debugging symbols loaded, so that stack trace is going to be pretty incomprehensible. Still, it might at least give us a hint of whether the crash is occurring on a lua binary instruction, or if it's something deeper down inside one of the system libraries.

We depend on the stability of the glibc ABI for these binaries to keep working. But I was able to get a prompt with the current Lua binary (compiled in 2015) and glibc 2.38 (the latest stable).