[asterisk-bugs] [JIRA] (ASTERISK-30380) res_pjsip: Crash in simple

Thu Dec 29 04:13:05 CST 2022

    [ https://issues.asterisk.org/jira/browse/ASTERISK-30380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261085#comment-261085 ] 

Joshua C. Colp edited comment on ASTERISK-30380 at 12/29/22 4:12 AM:
---------------------------------------------------------------------

The assertion that is failing:

{code}
    PJ_ASSERT_RETURN(tdata->msg->type == PJSIP_REQUEST_MSG,
                     PJSIP_ENOTREQUESTMSG);
{code}

Which I would expect to turn into a return in release mode. The documentation says to use "-DNDEBUG" and not "-DNDEBUG=1" so I don't know if that would make a difference. I believe this is fundamentally a build issue outside of Asterisk and is strictly with how PJSIP is being built. I'm not that familiar with it, we determined the ideal build for Asterisk for bundled years ago at this point and it rarely changes. Our config_site.h is here[1] which generally controls things.

[1] https://github.com/asterisk/asterisk/blob/20/third-party/pjproject/patches/config_site.h

was (Author: jcolp):
The assertion that is failing:

{code}
    PJ_ASSERT_RETURN(tdata->msg->type == PJSIP_REQUEST_MSG,
                     PJSIP_ENOTREQUESTMSG);
{code}

Which I would expect to turn into a return in release mode. The documentation says to use "-DNDEBUG" and not "-DNDEBUG=1" so I don't know if that would make a difference. I believe this is fundamentally a build issue outside of Asterisk.

You can look at how we build in release mode and see if that provides any help.

> res_pjsip: Crash in simple
> --------------------------
>
>                 Key: ASTERISK-30380
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30380
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: General
>    Affects Versions: 20.0.0, 20.1.0
>         Environment: Gentoo Linux x86_64 - Asterisk ebuild in portage tree
>            Reporter: Reuben Farrelly
>            Assignee: Reuben Farrelly
>         Attachments: core-asterisk-2022-12-28T23-40-58Z-brief.txt, core-asterisk-2022-12-28T23-40-58Z-full.txt, core-asterisk-2022-12-28T23-40-58Z-info.txt, core-asterisk-2022-12-28T23-40-58Z-locks.txt, core-asterisk-2022-12-28T23-40-58Z-thread1.txt, core-asterisk-2022-12-29T01-51-49Z-brief.txt, core-asterisk-2022-12-29T01-51-49Z-full.txt, core-asterisk-2022-12-29T01-51-49Z-info.txt, core-asterisk-2022-12-29T01-51-49Z-locks.txt, core-asterisk-2022-12-29T01-51-49Z-thread1.txt
>
>
> Asterisk is crashing frequently for me with the following printed in the system dmesg:
> [463264.572879] Code: 49 89 f0 8b b7 80 00 00 00 48 8d 97 88 00 00 00 31 c9 e9 f9 d3 ff ff 66 0f 1f 84 00 00 00 00 00 41 54 41 bc 0d 9c 02 00 55 53 <48> 8b 86 88 01 00 00 8b 10 85 d2 75 5b 48 89 fb 48 8b 7f 30 48 89
> [465079.782571] asterisk[5122]: segfault at 188 ip 00007f785395ed9a sp 00007f78514b5890 error 4 in libpjsip-simple.so.2[7f785395c000+a000] likely on CPU 1 (core 1, socket 0)
> [465079.782580] Code: 49 89 f0 8b b7 80 00 00 00 48 8d 97 88 00 00 00 31 c9 e9 f9 d3 ff ff 66 0f 1f 84 00 00 00 00 00 41 54 41 bc 0d 9c 02 00 55 53 <48> 8b 86 88 01 00 00 8b 10 85 d2 75 5b 48 89 fb 48 8b 7f 30 48 89
> [466895.025012] asterisk[5307]: segfault at 188 ip 00007fdd6445cd9a sp 00007fdd15f8a890 error 4 in libpjsip-simple.so.2[7fdd6445a000+a000] likely on CPU 3 (core 3, socket 0)
> [466895.025028] Code: 49 89 f0 8b b7 80 00 00 00 48 8d 97 88 00 00 00 31 c9 e9 f9 d3 ff ff 66 0f 1f 84 00 00 00 00 00 41 54 41 bc 0d 9c 02 00 55 53 <48> 8b 86 88 01 00 00 8b 10 85 d2 75 5b 48 89 fb 48 8b 7f 30 48 89
> This is with Asterisk-20.0.0 and 20.1.0-rc1.  Gentoo policy is that bundled libraries are not used so I am using the Gentoo portage pjsip (2.13).
> I have followed the instructions around generating a backtrace and will attach these soon.  However in short this is what is printed:
> Thread 71 (Thread 0x7f7865b6f6c0 (LWP 5096)):
> #0  0x00007f7865cc70ca in fdatasync () at /lib64/libc.so.6
> #1  0x00007f786643bc81 in unixSync () at /usr/lib64/libsqlite3.so.0
> #2  0x00007f7866489aab in syncJournal.part.0 () at /usr/lib64/libsqlite3.so.0
> #3  0x00007f7866495786 in sqlite3PagerCommitPhaseOne.part.0 () at /usr/lib64/libsqlite3.so.0
> #4  0x00007f7866496a3b in sqlite3BtreeCommitPhaseOne.part.0 () at /usr/lib64/libsqlite3.so.0
> #5  0x00007f7866498c28 in sqlite3VdbeHalt () at /usr/lib64/libsqlite3.so.0
> #6  0x00007f78664d09a4 in sqlite3VdbeExec () at /usr/lib64/libsqlite3.so.0
> #7  0x00007f78664d3ca6 in sqlite3_step () at /usr/lib64/libsqlite3.so.0
> #8  0x00007f78664d47ad in sqlite3_exec () at /usr/lib64/libsqlite3.so.0
> #9  0x000055f1869c29ec in db_execute_sql (sql=0x55f186b8563b "COMMIT", callback=0x0, arg=0x0) at db.c:315
>         errmsg = 0x0
>         res = 0
>         __FUNCTION__ = "db_execute_sql"
> #10 0x000055f1869c2a9b in ast_db_commit_transaction () at db.c:331
> #11 0x000055f1869c576c in db_sync_thread (data=0x0) at db.c:1148
>         __PRETTY_FUNCTION__ = "db_sync_thread"
> sqlite was updated on this system from 3.39 to 3.40 on November 25th which could be related.  Either way, Asterisk should not be crashing and restarting like this.
> These crashes happen every 30 minutes or so.
> I do not have sqlite configured anywhere in asterisk.

--
This message was sent by Atlassian JIRA
(v6.2#6252)