asterisk1.8 segfaults with wrong extension.lua (bug?)

I’m trying to migrate some macro from extensions.conf to extensions.lua. First time I am wrote wrong macro definition and gets segfault from asterisk (from /var/log/messages):

1st time I’m get segfault on CentOS6.2 x86_64 with asterisk (from EPEL).
For trying to reproduse I get Debian 6.0.3 i686 and asterisk from Digium repo Asterisk and put this dummy wrong macro in extensions.lua.

~# /etc/init.d/asterisk restart Stopping Asterisk PBX: asterisk. Starting Asterisk PBX: asterisk.
Hmm… Maybe all ok?
But in /var/log/messages

Evil :smiling_imp: file:

[code]# cat /etc/asterisk/extensions.lua
CONSOLE = “Console/dsp” – Console interface for demo

extensions = {}
extensions.incoming = {}

extensions[“macro-evilmacro”] = function()

Howto reproduce: copy this extensions.lua and try to restart asterisk.

For other errors i’m get correct error messages from pbx_lua (not segfaults).

Workly macro with visibility in extensions.conf:

extensions = { ["macro-goodmacro"] ={ ["s"] = function() app.verbose("yep") end; }; };

PS sorry for my English :blush:

I believe macros are deprecated and, for example, AEL actually uses subroutines to implement them. I’d therefore suggest they are high risk in any new front end language.

If you get a segmentation fault, you should first eliminate the possibility that you still have old versions of modules installed, although this normally causes problems at startup. Otherwise there is a very strong presumption of a bug and you should refer to: … +Backtrace

Maybe. At now, I’m migrate from asterisk 1.4 to 1.8 with big externsions.conf with some macro. Then it will be refactored, yep.

Asterisk, extensions and lua installed from distro repositories. And runs without segfaults in other cases.

As I understood from debugging (although I’m not an expert in this) - the problem in lua.

Now, I can’t reproduce problem on Debian, but, when I’m trying to call to extension where macro is present, I get segfault.
From CLI asterisk die silently, but running via gbd: I seen a message:

[code] – Executing [xxxxxxx@test_calls:2] Macro(“Console/dsp”, "evilmacro,“123"”) in new stack
[New Thread 0xb53ecb70 (LWP 1813)]
PANIC: unprotected error in call to Lua API (attempt to index a function value)
[Thread 0xb53ecb70 (LWP 1813) exited]

Program exited with code 01.

Maybe. At now, I’m migrate from asterisk 1.4 to 1.8 with big externsions.conf with some macro. Then it will be refactored, yep.

I’m not familiar with LUA, but with AEL, macros have never been coded using the pseudo-contexts from extensions.conf. Although it is a bug for it to crash the whole process, my guess would be that the LUA logic got completely confused when the low level code tried to process a macro in the extensions.conf way. As LUA seems to be very recent, I would expect to have a similar policy to AEL, except, possibly, that there is no support for macros at all.

I’m got idea from this … os%2FGoSub

Othervise they can’t seen in extensions.conf.
At the end of the 1st post I type workly example (but I do not know how it is correct) LUA macro, visible in extensions.conf.