FRACK error (Chan_sip)

Asterisk Asterisk SIP
1

Hello,
We have Asterisk periodically freezes. with such a mistake:

[2022-08-16 17:52:19] ERROR[6434] channel.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f1e4002e370 (0)
[2022-08-16 17:52:19] ERROR[6434] : Got 15 backtrace records

0: /usr/sbin/asterisk(__ast_assert_failed+0x84) [0x5c0aee]

1: /usr/sbin/asterisk() [0x45e492]

2: /usr/sbin/asterisk(__ao2_lock+0x64) [0x45e4f8]

3: /usr/sbin/asterisk(ast_softhangup+0x3f) [0x49bffc]

4: /usr/lib64/asterisk/modules/chan_sip.so(+0x9e1aa) [0x7f21ca4d01aa]

5: /usr/lib64/asterisk/modules/chan_sip.so(+0xa12f8) [0x7f21ca4d32f8]

6: /usr/lib64/asterisk/modules/chan_sip.so(+0xa82ed) [0x7f21ca4da2ed]

7: /usr/lib64/asterisk/modules/chan_sip.so(+0xb3aed) [0x7f21ca4e5aed]

8: /usr/lib64/asterisk/modules/chan_sip.so(+0xb456a) [0x7f21ca4e656a]

9: /usr/lib64/asterisk/modules/chan_sip.so(+0x17f37) [0x7f21ca449f37]

#10: /usr/lib64/asterisk/modules/chan_sip.so(+0x16a46) [0x7f21ca448a46]
#11: /usr/sbin/asterisk() [0x5ad901]
#12: /usr/sbin/asterisk() [0x5bde5f]
#13: /lib64/libpthread.so.0(+0x7ea5) [0x7f22232d8ea5]
#14: /lib64/libc.so.6(clone+0x6d) [0x7f22223778dd]

[2022-08-16 17:52:19] ERROR[6434] channel.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f1e4002e370 (0)
[2022-08-16 17:52:19] ERROR[6434] : Got 18 backtrace records

0: /usr/sbin/asterisk(__ast_assert_failed+0x84) [0x5c0aee]

1: /usr/sbin/asterisk() [0x45e492]

2: /usr/sbin/asterisk(__ao2_lock+0x64) [0x45e4f8]

3: /usr/sbin/asterisk() [0x497c9a]

4: /usr/sbin/asterisk(ast_queue_frame+0x2a) [0x4984cc]

5: /usr/sbin/asterisk(ast_softhangup_nolock+0xb0) [0x49bf53]

6: /usr/sbin/asterisk(ast_softhangup+0x50) [0x49c00d]

7: /usr/lib64/asterisk/modules/chan_sip.so(+0x9e1aa) [0x7f21ca4d01aa]

8: /usr/lib64/asterisk/modules/chan_sip.so(+0xa12f8) [0x7f21ca4d32f8]

9: /usr/lib64/asterisk/modules/chan_sip.so(+0xa82ed) [0x7f21ca4da2ed]

#10: /usr/lib64/asterisk/modules/chan_sip.so(+0xb3aed) [0x7f21ca4e5aed]
#11: /usr/lib64/asterisk/modules/chan_sip.so(+0xb456a) [0x7f21ca4e656a]
#12: /usr/lib64/asterisk/modules/chan_sip.so(+0x17f37) [0x7f21ca449f37]
#13: /usr/lib64/asterisk/modules/chan_sip.so(+0x16a46) [0x7f21ca448a46]
#14: /usr/sbin/asterisk() [0x5ad901]
#15: /usr/sbin/asterisk() [0x5bde5f]
#16: /lib64/libpthread.so.0(+0x7ea5) [0x7f22232d8ea5]
#17: /lib64/libc.so.6(clone+0x6d) [0x7f22223778dd]

We use
FreePBX 14.0.13.34
Asterisk 16.11.0

Tell me also why when I look at the log files, through the FreePBX web interface.
One user sees the full log (the one that I specified yours), and the second user only frak errors (without a full report), like this:

[2022-08-16 17:52:19] ERROR[6434] channel.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f1e4002e370 (0)
[2022-08-16 17:52:19] ERROR[6434] channel.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f1e4002e370 (0)

2

This is the wrong forum to ask about FreePBX. If you want to look at the full log, you should obtain a Linux shell (e.g. log in at the the physical console, or use ssh), and use an editor (e.g vi, or nano), or a pager (e.g. more or less), to examine /var/log/asterisk/full.

Bad magic numbers are caused by memory corruption, which may have occurred some time before and the fault may be in a different thread. As such they can be very difficult to debug, and often rely on one picking up patterns in the events leading up to them.

If upgrading to Asterisk 18.13.0 doesn’t fix it, and it really is in chan_sip, it is unlikely to get fixed as chan_sip is deprecated and I believe has no active maintainer.

Asterisk 16 is almost at the end of its mainstream support, so probably not worth considering as a replacement, any longer.

To allow any further analysis, you should obtain proper crash dump analyses, as described in:

https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace

Note that the binaries of Asterisk supplied in FreePBX packages are not suitable for debugging, and you will probably need to rebuild from source. I think there may be symbol table packages, but you really need to build with optimise disabled, and, as this involves locks, enabling thread debugging may also be desirable.

Rather than waste time on chan_sip, you should upgrade to chan_pjsip, unless you know a very specific reason why this will not work (ITSPs often claim they don’t support it when they really mean they haven’t tried).

3

What David said is correct, but if you do upgrade to Asterisk 18.13.0 and the issue still happens, you should regardless file an issue on the Asterisk issue tracker at https://issues.asterisk.org

You’ll need to attach the backtrace and do the other things as described above. There is, of course, no guarantee that it will be fixed, but given that this is a bug, there is still a possibility of the problem being addressed in a future release. No active maintainer just means Sangoma doesn’t devote resources to it, but it’s community supported like most things in Asterisk.

4

I think no active maintainer means that no-one in the community is paying much attention either, i.e. individuals may submit fixes, but no-one is coordinating maintenance.

5

Correct, but really the majority of stuff in Asterisk has “no active maintainer”. Very little of Asterisk has any active maintainer, and even the stuff that does have an active maintainer, comes with no guarantee whatsoever that any issues will ever be fixed. That is just the nature of the project. There isn’t the manpower for it.

I get that chan_sip has a special warning about no active maintainer, and we want people to move away from it, but to some extent it just seems like FUD because there’s nothing particularly special about chan_sip. There is no guarantee an issue will be fixed, but someone in the community can choose to look at the issue and if fixed, it will probably get merged since bug fixes are eligible for inclusion. This is the same as any other community supported module.

To my point, people should always feel free to report issues, with the expectation up front that there is no guarantee such an issue will be resolved, whether it has an active maintainer or not.

6

Dont think bugs in chan_sip are going to be fixed. It goes away next year. Does this happen in chan_pjsip?

7

Dont think bugs in chan_sip are going to be fixed. It goes away next year.

It’s not likely, but it can happen. It really depends on the bug: what the impact is, who is affected, and how easy it is to fix.

The same is true of issues in general.

Does this happen in chan_pjsip?

Sure, it happens with everything.

Take a look at this PJSIP issue: ASTERISK-28689: res_pjsip: Crash when locking group lock when sending stateful response

The issue has been duplicated EIGHT times. PJSIP definitely has an active maintainer (Sangoma), and there has been no attention devoted to this issue (and PJSIP is Sangoma’s baby).

This just goes to show that nothing is guaranteed (I’m not criticizing Sangoma, just pointing out that this is the reality). Having an active maintainer doesn’t guarantee issues will be fixed, and not having one doesn’t mean they won’t.

Often, issue resolutions depend on the issue itself and its nuances, not always whether a module has a “maintainer”. It’s not so black and white.

8

The question was does this specific issue happen in chan_pjsip, which is unknown. Not “do crashes happen elsewhere” which is of course yes.

9

So this exact issue being reported happens in everything? Chan_pjsip, chan_iax, chan_local because you know, happens in everything. I’m not sure how unrelated issues are relevant to this specific issue happening in chan_sip.

10

As file indicated, I was referring to how bugs are treated in the project, not this specific issue, making a general point about what it really means for a module to have a maintainer.

Disregard my comment inasmuch as this issue is concerned.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.