Each time someone reports a bug, they can and must provide reproduction instructions.

Well, not really "must", but it sure does help if you do so. Without that, there's not a whole lot we can do unless we can guess how to reproduce the error on our own.

Hi @Rical, thanks for taking the time to report this!
Unfortunately this report lacks some information. If you have time and can still reproduce the problem, please add a more complete description to this report. Ideally, exact and clear steps to reproduce should allow any other person to follow these steps (without having to interpret those steps) and see the same results. Problems that others can reliably reproduce can get fixed faster. Thanks!

• To protect central modules T135845 against runing errors which "kill" pages my antiCollapse() function masks the error, add a category-alert and replace the error with a <ref> containing the detailed error description.

function events.antiCollapse(options, content_or_func, ...)

• The chain of call is : any function or string generator can contain an error depending of use cases.
• Any of these codes can be included in antiCollapse().
• For a strong code, inside it, the code must adapt itself to any use case (string, function, table, nil).
• To debug my code I must try some cases and adapt the code at any level and for any case.
• Without knowing where the error is detected, that is very hard.
• To see it in live, search "antiCollapse" in code and content in https://fr.wikisource.org/wiki/Module:Central-fr-ws ( size 1 MBi ).

How to debug the parser:

• You know where the parser activates "Erreur Lua : attempt to call a string value", search it in the parser-code.
• There, many other errors add some datas: the module, the function and the line of code.
• But some errors do not add these datas and could do that.
• Add these datas for the error code of this task do not need to know the detection point.
• But, after detection, need only to do the same as many other errors.

@Rical A cursory look at that module reveals that you're using "select" as a variable name in it. That's a bad idea, since it's the name of a built-in global function. It wouldn't surprise me if that were the root of the problem.

I edit the code in local JEdit and it not shows "select" as a reserved word. But now I replace "select" by "selector".
I change and try the code hundreds times each day and register it only when a function is enough debuged and understandable for Lua-coders.
Show a code resulting in a bug which kills the page is not possible.
I can only form a test which fails when 1 line change. I will do it.

I suspend the antiCrash() development to not delay central modules.
But I continue to ask the same description for all runtime errors in modules : module name, line, function and details.

In T154769#2928736, @Rical wrote:

But I continue to ask the same description for all runtime errors in modules : module name, line, function and details.

That already all exists. You get it when an error makes it back to the console or wikitext without (x)pcall catching it.