I have a strange problem and I’m looking for suggestions on how to investigate
it.
I have a dialplan which is processing a call, and Asterisk simply stops doing
anything for that call.
I have verbose and debug logging turned on.
There are two steps at a particular point in the dialplan:
Set(UserCredit=${ODBC_GENERIC(select Credit('${DDI}'))})
Verbose(6,Current credit level for user ${DDI} is ${UserCredit} pence)
Everything gets processed up to and including the first line - the verbose log
file shows me:
pbx.c:2946 in pbx_extension_helper: Executing [0044xxxx509903@DialBleg:46]
Set(“SIP/TrunkTwo-00001184”, “UserCredit=999”) in new stack
(Phone number obscured here for anonymity).
Then, that is it. Nothing further happens with call processing (until one of
the parties hangs up) and the second dialplan command above never appears in
the verbose log file. I have several other Verbose(6,…) commands preceding
this, and they all output into the log file as expected.
If another call arrives on the same server, Asterisk quite happily starts
processing it and records what it’s doing in the log files.
Can anyone suggest how I can investigate what Asterisk is doing at the point
where it “gets stuck”, and how to find out why it simply stops processing the
call and doesn’t continue with the dialplan commands?
Apologies for omitting the version number - it’s 16.28.0 installed as a Debian package.
In terms of a backtrace, am I reading the documentation you linked to correctly, that in order to get that information, I have to compile Asterisk from source!?
I can’t speak for how the Debian packages are built or what are available there, but if Asterisk is built optimized and stripped then the backtrace is useless, because it has no details about what is executing at the time.
It shows there are no symbol tables, but not whether or not it was optimised, although it is likely that it was optimised.
It is possible that there is a separate file containing the debug information. If there is it may be in a different package. That’s how it is done for the kernel, itself. It actually looks as though they have done this for the sid (unstable release) and Asterisk 1.20, but not for earlier versions.
However, if you are in to serious debugging, distribution packages are not the way to go, as, for example, in this case, the Asterisk version is no longer supported, so you would eventually be asked to move to 18, (19), or 20.
In theory, the packager should have taken responsibility for maintenance, but, in practice, I think it is unlikely you will get any help from that direction.
Well, there is no “asterisk-debug” or similar package in Debian, so I think
it’s unlikely that the package maintainers have allowed for this requirement
in debugging a problem.
I suspect they provide such a package in sid simply because that’s the
unstable release, and all sorts of stuff is expected to break, so they
automatically provide as much assistance with investigating that as possible.
As for me being “into serious debugging”, I don’t mind collecting verbose and
debug logs of applications in order to find out what’s going on, but in this
instance I’m simply trying to work out why Asterisk stops at a ridiculous
point in the dialplan (it’s even inside a subroutine context which gets called
from two different places, and one of them works fine) - I wasn’t expecting to
be told to recompile Asterisk for myself (which might well result in a version
which handles the dialplan fine, whereas the packaged version fails, leaving me
none the wiser, who knows).
I’ll see what time I can find in the next few days to take this further.
I agree very much that it’s unlikely the Debian package maintainers are going
to assist with Asterisk simply stopping in the middle of a dialplan - they are
almost certainly going to tell me to “talk to the Asterisk people”.
The bit I still find most bizarre is that Asterisk itself has not stopped - the
same binary running on the same server will happily start processing another
call which comes in just a few seconds later.
Asterisk is multithreaded. A single thread can be blocked on something while others are fine, allowing those to operate normally. Each channel executing in the dialplan is its own thread.
The issue is that package makers continue to use end of life versions of software, and possibly create non-standard hybrids, by back porting security fixes from later versions. Generally the original maintainer will only want to debug unmodified current versions.
This dilemma (current supported version from the developers, vs. packaged
version from the distribution) is the main reason why I like applications
which have their own RPM and DEB repositories, ensuring that users can install
supported code, guaranteed to be built the correct way, and maintainable for
future upgrades.
Otherwise you have to choose between the convenience of packaged code which is
the same as everyone else’s installation of that version, and comes with
automatic upgrades, or else you spend time building your own binary and hope
it’s built correctly, in order to get support from developers who quite
understandably only want to deal with current releases.