BT Analysis | asterisk fall

[leonardo]

Dear.

Through the bt log is it possible to analyze the cause of the asterisk crash that we had recently?

(gdb) bt
#0 0x00007f7a3be604fb in raise () from /lib64/libpthread.so.0
#1 0x00007f79d1fd76c6 in skgesigOSCrash () from /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1
#2 0x00007f79d2288f79 in kpeDbgSignalHandler () from /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1
#3 0x00007f79d1fd78d6 in skgesig_sigactionHandler () from /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1
#4
#5 0x00007f7a3ae2e387 in raise () from /lib64/libc.so.6
#6 0x00007f7a3ae2fa78 in abort () from /lib64/libc.so.6
#7 0x00007f7a3ae70f67 in __libc_message () from /lib64/libc.so.6
#8 0x00007f7a3ae79329 in _int_free () from /lib64/libc.so.6
#9 0x00007f7a3dadf536 in cpool_release_pool (pf=0x7f7951402280 , pool=0x7f79f401b8f0) at …/src/pj/pool_caching.c:259
#10 0x00007f7a3dadcb78 in grp_lock_destroy (p=0x7f79f401b998) at …/src/pj/lock.c:397
#11 grp_lock_dec_ref (glock=0x7f79f401b998) at …/src/pj/lock.c:555
#12 pj_grp_lock_dec_ref (glock=0x7f79f401b998) at …/src/pj/lock.c:646
#13 0x00007f7a3dadccb5 in grp_lock_release (p=) at …/src/pj/lock.c:335
#14 pj_grp_lock_release (grp_lock=) at …/src/pj/lock.c:488
#15 0x00007f7a3da80902 in on_cache_timeout (timer_heap=, entry=) at …/src/pjnath/stun_session.c:249
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

There was only one call that completed successfully and then the asterisk crashed.

If you need more information, please let me know and I’ll be providing it!

Thanks!

[jcolp]

Something to do with the STUN client. That’s the extent of what I can say.

[david551]

It’s freeing memory that it didn’t allocate or has already freed.

[leonardo]

And is there any fix for this?

What can we do to prevent this from happening again?

[jcolp]

You haven’t stated a version of Asterisk. Such an issue existed in the past but was fixed by the creators of PJSIP, and I haven’t seen it since.

[leonardo]

I see, asterisk version is 13.38.3.

So to fix the problem reported above would be the update to the latest version ?

[jcolp]

It could certainly be.

[david551]

This sort of failure can be very difficult to diagnose. Joshua is saying that that a similar problem has been fixed in later versions, but that doesn’t guarantee that you haven’t found a new error. It isn’t like a configuration error, where there is a user error to correct.

In any case Asterisk 13 is over a year since end of life and hasn’t been fully supported for over two years.

[Chano]

For upgrading I would recommend sticking with LTS version for mission critical systems, to avoid stuff breaking on upgrades. Not that I’ve had much stuff break the last 13 years, but modules are removed from time to time, and functionality changed. Sticking with an LTS version will give you longer between potentially breaking upgrades. (Never had stuff break from eg. 13.0 til 13.1, but have had stuff break from eg. 13.0 to 16.0.)

Current LTS is version 20, and should be good for about another 3 years.

For less critical systems, or very simple setups, the latest and greatest will do just fine. Eg. a small business with couple of phone lines and queues, and a handful of extensions, especially when using a frontend like FreePBX, should be just fine running the latest non-LTS version. But a telco or a large business with a complicated and highly customized dialplan should probably stick with LTS, unless comprehensive compatibility testing of the phone system every year seems like a good use of employee time.