Pjsip在RegState回调中崩溃 [英] Pjsip Crashed on RegState callback
本文介绍了Pjsip在RegState回调中崩溃的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
在扩展SipAccount类的类中，我经常收到onRegState()回调，我注意到在稍后几次回调(如第4次或第5次)崩溃后，进行了几次回调.
In my class that extends SipAccount class I've onRegState() callback which i receive frequently I've notice that after few callback later at any callback like 4th or 5th time it crashes.
这是onRegState()回调中的代码
this is the code from onRegState() callback
@Override
public void onRegState(OnRegStateParam prm)
{
Log.d(TAG, "onRegState...");
PresenceStatus prsenStatus = new PresenceStatus();
if (prm.getCode().swigValue()/100 == 2)
{
Log.d(TAG, "Going online!");
listener.onLogIn(true);
prsenStatus.setStatus(pjsua_buddy_status.PJSUA_BUDDY_STATUS_ONLINE);
}
else
{
Log.d(TAG, "Going offline!");
listener.onLogIn(false);
prsenStatus.setStatus(pjsua_buddy_status.PJSUA_BUDDY_STATUS_OFFLINE);
}
try
{
sipAccount.setOnlineStatus(prsenStatus);
}
catch (Exception e)
{
e.printStackTrace();
}
}
这是来自pjsip客户端的日志.
This is the log from pjsip client.
06-21 12:37:16.172 10428-10645/com.safarifone.waafi A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 10645 (Thread-3816)
06-21 12:37:16.279 184-184/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-21 12:37:16.279 184-184/? I/DEBUG: Build fingerprint: 'google/occam/mako:5.1.1/LMY48T/2237560:user/release-keys'
06-21 12:37:16.279 184-184/? I/DEBUG: Revision: '11'
06-21 12:37:16.279 184-184/? I/DEBUG: ABI: 'arm'
06-21 12:37:16.279 184-184/? I/DEBUG: pid: 10428, tid: 10645, name: Thread-3816 >>> com.safarifone.waafi <<<
06-21 12:37:16.279 184-184/? I/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
06-21 12:37:16.374 184-184/? I/DEBUG: r0 00000000 r1 00002995 r2 00000006 r3 00000000
06-21 12:37:16.374 184-184/? I/DEBUG: r4 a2950dd8 r5 00000006 r6 0000000b r7 0000010c
06-21 12:37:16.374 184-184/? I/DEBUG: r8 b89629b8 r9 b89629b8 sl b6e66155 fp a29502a4
06-21 12:37:16.374 184-184/? I/DEBUG: ip 00002995 sp a2950238 lr b6e66989 pc b6e8be24 cpsr 600f0010
06-21 12:37:16.375 184-184/? I/DEBUG: backtrace:
06-21 12:37:16.375 184-184/? I/DEBUG: #00 pc 0003be24 /system/lib/libc.so (tgkill+12)
06-21 12:37:16.375 184-184/? I/DEBUG: #01 pc 00016985 /system/lib/libc.so (pthread_kill+52)
06-21 12:37:16.375 184-184/? I/DEBUG: #02 pc 00017597 /system/lib/libc.so (raise+10)
06-21 12:37:16.375 184-184/? I/DEBUG: #03 pc 00013d3d /system/lib/libc.so (__libc_android_abort+36)
06-21 12:37:16.375 184-184/? I/DEBUG: #04 pc 000124ec /system/lib/libc.so (abort+4)
06-21 12:37:16.376 184-184/? I/DEBUG: #05 pc 00464d10 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (__gnu_cxx::__verbose_terminate_handler()+348)
06-21 12:37:16.376 184-184/? I/DEBUG: #06 pc 0045e9e4 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (__cxxabiv1::__terminate(void (*)())+8)
06-21 12:37:16.376 184-184/? I/DEBUG: #07 pc 0045ea84 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (std::terminate()+12)
06-21 12:37:16.376 184-184/? I/DEBUG: #08 pc 0045ec10 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (__cxa_throw+156)
06-21 12:37:16.376 184-184/? I/DEBUG: #09 pc 000d6c00 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (SwigDirector_Account::onRegState(pj::OnRegStateParam&)+400)
06-21 12:37:16.376 184-184/? I/DEBUG: #10 pc 0015ef9c /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (pj::Endpoint::on_reg_state2(int, pjsua_reg_info*)+268)
06-21 12:37:16.376 184-184/? I/DEBUG: #11 pc 001996c0 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (regc_cb+1424)
06-21 12:37:16.376 184-184/? I/DEBUG: #12 pc 001dc944 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (call_callback+124)
06-21 12:37:16.376 184-184/? I/DEBUG: #13 pc 001ddc28 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (regc_tsx_callback+2120)
06-21 12:37:16.377 184-184/? I/DEBUG: #14 pc 00225a18 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (mod_util_on_tsx_state+232)
06-21 12:37:16.377 184-184/? I/DEBUG: #15 pc 00221304 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (tsx_set_state+540)
06-21 12:37:16.377 184-184/? I/DEBUG: #16 pc 00224dfc /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (tsx_on_state_proceeding_uac+712)
06-21 12:37:16.377 184-184/? I/DEBUG: #17 pc 002240cc /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (tsx_on_state_calling+656)
06-21 12:37:16.377 184-184/? I/DEBUG: #18 pc 002227a0 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (pjsip_tsx_recv_msg+180)
06-21 12:37:16.377 184-184/? I/DEBUG: #19 pc 002206ac /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (mod_tsx_layer_on_rx_response+232)
06-21 12:37:16.377 184-184/? I/DEBUG: #20 pc 002052b4 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (pjsip_endpt_process_rx_data+696)
06-21 12:37:16.377 184-184/? I/DEBUG: #21 pc 002055d0 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (endpt_on_rx_msg+636)
06-21 12:37:16.377 184-184/? I/DEBUG: #22 pc 0020f6b4 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (pjsip_tpmgr_receive_packet+1908)
06-21 12:37:16.377 184-184/? I/DEBUG: #23 pc 002152e8 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (on_data_read+252)
06-21 12:37:16.378 184-184/? I/DEBUG: #24 pc 00351ce0 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (ioqueue_on_read_complete+208)
06-21 12:37:16.378 184-184/? I/DEBUG: #25 pc 00347a14 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (ioqueue_dispatch_read_event+940)
06-21 12:37:16.378 184-184/? I/DEBUG: #26 pc 0034a1a8 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (pj_ioqueue_poll+1408)
06-21 12:37:16.378 184-184/? I/DEBUG: #27 pc 00204e20 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (pjsip_endpt_handle_events2+328)
06-21 12:37:16.378 184-184/? I/DEBUG: #28 pc 001ae420 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (pjsua_handle_events+92)
06-21 12:37:16.378 184-184/? I/DEBUG: #29 pc 001ab320 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (worker_thread+32)
06-21 12:37:16.378 184-184/? I/DEBUG: #30 pc 0034b9c8 /data/app/com.safarifone.waafi-1/lib/arm/libpjsua2.so (thread_main+176)
06-21 12:37:16.378 184-184/? I/DEBUG: #31 pc 00016173 /system/lib/libc.so (__pthread_start(void*)+30)
06-21 12:37:16.379 184-184/? I/DEBUG: #32 pc 0001409b /system/lib/libc.so (__start_thread+6)
推荐答案
前言
我也在这个问题上苦苦挣扎了几个月，并且在现实世界中的应用使用情况(游戏市场的崩溃)中也遇到了同样的情况.并使用您的代码来处理注册结果.
I was also struggling on this problem for several months and got the same on the real-world app usage (crashes form the play market). And used your code to handle registration results.
困难之处在于，我们无法在任何设备上进行测试时遇到此类问题，但用户每1000次安装(大约很高)崩溃了500次.
The difficult was that we couldn't experience that issues during our tests on any of our devices but our users got it approx 500 crashes per 1000 installs (very high).
最初，我是从UI线程处理Pjsip的，然后尝试为Pjsip创建我自己的线程(使用 uaConfig.setThreadCnt(0)和 uaConfig.setMainThreadOnly(true))，但是它根本无法正常工作，或者我不知道如何正确执行此操作，而且在任何地方都没有任何线索.然后，我将所有业务逻辑从UI移到工作线程，并从工作线程使用Pjsip.没有任何帮助，问题是相同的.
Initially I was dealing with Pjsip from UI thread, then I tried to create my own thread for the Pjsip (with uaConfig.setThreadCnt(0) and uaConfig.setMainThreadOnly(true)) but it failed to work at all, or I don't know how to do this right and there is no clue about it anywhere. Then I moved all our business logic from UI to worker thread and worked with Pjsip from worker thread. Nothing helped and the issues were the same.
最后，昨天我们能够解决此问题，同时我们将Pjsip日志设置为第9级.
Finally yesterday we were able to catch this issue and at the same time we had Pjsip logs turned on level 9.
这是此崩溃的完整日志，带有先前的信息(出于明显的原因，我已替换了实际的服务器凭据):
And here is the full log for this crash with preceding info (I've replaced actual server credentials for obvious reason):
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.474 sip_endpoint.c .Module "mod-pjsua-log" registered
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.475 sip_endpoint.c .Module "mod-tsx-layer" registered
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.475 sip_endpoint.c .Module "mod-stateful-util" registered
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.475 sip_endpoint.c .Module "mod-ua" registered
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.475 sip_endpoint.c .Module "mod-100rel" registered
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.475 sip_endpoint.c .Module "mod-pjsua" registered
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.475 sip_endpoint.c .Module "mod-invite" registered
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.475 android_jni_de ..Android JNI sound library initialized
09-07 19:27:49.475 25309-25328/? I/System.out: 19:27:49.475 pjlib ..select() I/O Queue created (0xd1f53214)
09-07 19:27:49.476 25309-25328/? I/System.out: 19:27:49.476 conference.c ..Creating conference bridge with 12 ports
09-07 19:27:49.476 25309-25328/? I/System.out: 19:27:49.476 Master/sound ..Using delay buffer with WSOLA.
09-07 19:27:49.477 25309-25328/? I/System.out: 19:27:49.477 pjsua_vid.c ..Initializing video subsystem..
09-07 19:27:49.478 25309-25328/? I/System.out: 19:27:49.477 openh264.cpp ...OpenH264 codec initialized
09-07 19:27:49.478 25309-25328/? I/System.out: 19:27:49.478 opengl_dev.c ...OpenGL device initialized
09-07 19:27:49.489 25309-25328/? I/System.out: 19:27:49.489 android_dev.c ...Android video capture initialized with 0 device(s):
09-07 19:27:49.489 25309-25328/? I/System.out: 19:27:49.489 colorbar_dev.c ...Colorbar video src initialized with 2 device(s):
09-07 19:27:49.489 25309-25328/? I/System.out: 19:27:49.489 colorbar_dev.c ... 0: Colorbar generator
09-07 19:27:49.489 25309-25328/? I/System.out: 19:27:49.489 colorbar_dev.c ... 1: Colorbar-active
09-07 19:27:49.489 25309-25328/? I/System.out: 19:27:49.489 sip_endpoint.c .Module "mod-evsub" registered
09-07 19:27:49.490 25309-25328/? I/System.out: 19:27:49.490 sip_endpoint.c .Module "mod-presence" registered
09-07 19:27:49.490 25309-25328/? I/System.out: 19:27:49.490 evsub.c .Event pkg "presence" registered by mod-presence
09-07 19:27:49.490 25309-25328/? I/System.out: 19:27:49.490 sip_endpoint.c .Module "mod-mwi" registered
09-07 19:27:49.490 25309-25328/? I/System.out: 19:27:49.490 evsub.c .Event pkg "message-summary" registered by mod-mwi
09-07 19:27:49.490 25309-25328/? I/System.out: 19:27:49.490 sip_endpoint.c .Module "mod-refer" registered
09-07 19:27:49.490 25309-25328/? I/System.out: 19:27:49.490 evsub.c .Event pkg "refer" registered by mod-refer
09-07 19:27:49.490 25309-25328/? I/System.out: 19:27:49.490 sip_endpoint.c .Module "mod-pjsua-pres" registered
09-07 19:27:49.491 25309-25328/? I/System.out: 19:27:49.491 sip_endpoint.c .Module "mod-pjsua-im" registered
09-07 19:27:49.492 25309-25328/? I/System.out: 19:27:49.491 sip_endpoint.c .Module "mod-pjsua-options" registered
09-07 19:27:49.492 25309-25328/? I/System.out: 19:27:49.492 pjsua_core.c .1 SIP worker threads created
09-07 19:27:49.492 25309-25328/? I/System.out: 19:27:49.492 pjsua_core.c .pjsua version 2.6-svn for Linux-3.10.73/armv8l initialized
09-07 19:27:49.492 25309-25328/? I/System.out: 19:27:49.492 pjsua_core.c .PJSUA state changed: CREATED --> INIT
09-07 19:27:49.496 25309-25328/? I/System.out: 19:27:49.496 pjsua_core.c SIP UDP socket reachable at 192.168.0.102:49790
09-07 19:27:49.496 25309-25328/? I/System.out: 19:27:49.496 udp0xc5e8bc00 SIP UDP transport started, published address is 192.168.0.102:49790
09-07 19:27:49.499 25309-25328/? I/System.out: 19:27:49.499 tcptp:39629 SIP TCP listener ready for incoming connections at 192.168.0.102:39629
09-07 19:27:49.499 25309-25328/? I/System.out: 19:27:49.499 pjsua_core.c PJSUA state changed: INIT --> STARTING
09-07 19:27:49.499 25309-25328/? I/System.out: 19:27:49.499 sip_endpoint.c .Module "mod-unsolicited-mwi" registered
09-07 19:27:49.499 25309-25328/? I/System.out: 19:27:49.499 pjsua_core.c .PJSUA state changed: STARTING --> RUNNING
09-07 19:27:49.523 25309-25328/? I/System.out: 19:27:49.523 pjsua_acc.c Adding account: id=sip:user85@192.168.0.1:5065;transport=tcp
09-07 19:27:49.523 25309-25328/? I/System.out: 19:27:49.523 pjsua_acc.c .Account sip:user85@192.168.0.1:5065;transport=tcp added with id 0
09-07 19:27:49.523 25309-25328/? I/System.out: 19:27:49.523 pjsua_acc.c .Acc 0: setting registration..
09-07 19:27:49.524 25309-25328/? I/System.out: 19:27:49.524 tcpc0xc8004414 ..TCP client transport created
09-07 19:27:49.525 25309-25328/? I/System.out: 19:27:49.525 tcpc0xc8004414 ..TCP transport 192.168.0.102:43292 is connecting to 192.168.0.1:5065...
09-07 19:27:49.525 25309-25328/? I/System.out: 19:27:49.525 pjsua_acc.c ..Contact for acc 0 updated: <sip:user85@192.168.0.102:43292;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000e922f243>"
09-07 19:27:49.526 25309-25328/? I/System.out: 19:27:49.526 endpoint ..Request msg REGISTER/cseq=27093 (tdta0xf2abe064) created.
09-07 19:27:49.526 25309-25328/? I/System.out: 19:27:49.526 tsx0xc5189864 ...Transaction created for Request msg REGISTER/cseq=27094 (tdta0xf2abe064)
09-07 19:27:49.526 25309-25328/? I/System.out: 19:27:49.526 tsx0xc5189864 ..Sending Request msg REGISTER/cseq=27094 (tdta0xf2abe064) in state Null
09-07 19:27:49.527 25309-25328/? I/System.out: 19:27:49.526 sip_resolve.c ...Target '192.168.0.1:5065' type=TCP resolved to '192.168.0.1:5065' type=TCP (TCP transport)
09-07 19:27:49.527 25309-25328/? I/System.out: 19:27:49.527 pjsua_core.c ...TX 670 bytes Request msg REGISTER/cseq=27094 (tdta0xf2abe064) to TCP 192.168.0.1:5065:
09-07 19:27:49.527 25309-25328/? I/System.out: REGISTER sip:192.168.0.1:5065;transport=tcp SIP/2.0
09-07 19:27:49.527 25309-25328/? I/System.out: Via: SIP/2.0/TCP 192.168.0.102:43292;rport;branch=z9hG4bKPjF2B-OwmauIYhdNKR-ZgJx.-1MSDez4W6;alias
09-07 19:27:49.527 25309-25328/? I/System.out: Max-Forwards: 70
09-07 19:27:49.527 25309-25328/? I/System.out: From: <sip:user85@192.168.0.1>;tag=4qxB-NvGjIr6mYvHsTZodmy3jlZbSaId
09-07 19:27:49.527 25309-25328/? I/System.out: To: <sip:user85@192.168.0.1>
09-07 19:27:49.527 25309-25328/? I/System.out: Call-ID: C5IqW1iZ3iPJDNHNPtQnk0L-9IoX3iUs
09-07 19:27:49.527 25309-25328/? I/System.out: CSeq: 27094 REGISTER
09-07 19:27:49.527 25309-25328/? I/System.out: User-Agent: Pjsua2 Android 2.6-svn
09-07 19:27:49.527 25309-25328/? I/System.out: Supported: outbound, path
09-07 19:27:49.527 25309-25328/? I/System.out: Contact: <sip:user85@192.168.0.102:43292;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000e922f243>"
09-07 19:27:49.527 25309-25328/? I/System.out: Expires: 300
09-07 19:27:49.527 25309-25328/? I/System.out: Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
09-07 19:27:49.527 25309-25328/? I/System.out: Content-Length: 0
09-07 19:27:49.527 25309-25328/? I/System.out: --end msg--
09-07 19:27:49.527 25309-25328/? I/System.out: 19:27:49.527 tsx0xc5189864 ...State changed from Null to Calling, event=TX_MSG
09-07 19:27:49.527 25309-25328/? I/System.out: 19:27:49.527 pjsua_acc.c ..Acc 0: Registration sent
09-07 19:27:49.629 25309-25449/? I/System.out: 19:27:49.628 tcpc0xc8004414 !TCP connect() error: Connection refused [code=120111]
09-07 19:27:49.631 25309-25449/? I/System.out: 19:27:49.629 tsx0xc5189864 Failed to send Request msg REGISTER/cseq=27094 (tdta0xf2abe064)! err=120111 (Connection refused)
09-07 19:27:49.632 25309-25449/? I/System.out: 19:27:49.631 tsx0xc5189864 State changed from Calling to Terminated, event=TRANSPORT_ERROR
09-07 19:27:49.634 25309-25449/? I/System.out: 19:27:49.633 pjsua_acc.c ..SIP registration failed, status=503 (Connection refused)
09-07 19:27:49.635 25309-25449/? I/System.out: 19:27:49.634 pjsua_acc.c ..Scheduling re-registration retry for acc 0 in 7 seconds..
09-07 19:27:49.900 25453-25449/? A/google-breakpad: Microdump skipped (uninteresting)
09-07 19:27:49.930 25309-25449/? W/google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
09-07 19:27:49.930 25309-25449/? W/google-breakpad: Chrome build fingerprint:
09-07 19:27:49.930 25309-25449/? W/google-breakpad: 10
09-07 19:27:49.930 25309-25449/? W/google-breakpad: 10
09-07 19:27:49.930 25309-25449/? W/google-breakpad: ### ### ### ### ### ### ### ### ### ### ### ### ###
09-07 19:27:49.933 25309-25449/? A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 25449 (Thread-18)
[ 09-07 19:27:49.940 16075:16075 W/ ]
debuggerd: handling request: pid=25309 uid=11700 gid=11700 tid=25449
09-07 19:27:49.970 25454-25454/? W/debuggerd: type=1400 audit(0.0:1124): avc: denied { search } for name="?" dev="dm-2" ino=441666 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
09-07 19:27:50.050 25454-25454/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-07 19:27:50.051 25454-25454/? A/DEBUG: Build fingerprint: 'google/bullhead/bullhead:7.1.2/N2G48C/4104010:user/release-keys'
09-07 19:27:50.051 25454-25454/? A/DEBUG: Revision: 'rev_1.0'
09-07 19:27:50.051 25454-25454/? A/DEBUG: ABI: 'arm'
09-07 19:27:50.051 25454-25454/? A/DEBUG: pid: 25309, tid: 25449, name: Thread-18 >>> ? <<<
09-07 19:27:50.051 25454-25454/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
09-07 19:27:50.051 25454-25454/? A/DEBUG: r0 00000000 r1 00006369 r2 00000006 r3 00000008
09-07 19:27:50.051 25454-25454/? A/DEBUG: r4 c3c01978 r5 00000006 r6 c3c01920 r7 0000010c
09-07 19:27:50.051 25454-25454/? A/DEBUG: r8 c545f7e0 r9 c4022858 sl c3ff8a50 fp ffffffff
09-07 19:27:50.051 25454-25454/? A/DEBUG: ip 00000000 sp c3c01048 lr f47e45e7 pc f47e6e44 cpsr 200f0010
09-07 19:27:50.063 25454-25454/? A/DEBUG: backtrace:
09-07 19:27:50.064 25454-25454/? A/DEBUG: #00 pc 00049e44 /system/lib/libc.so (tgkill+12)
09-07 19:27:50.064 25454-25454/? A/DEBUG: #01 pc 000475e3 /system/lib/libc.so (pthread_kill+34)
09-07 19:27:50.064 25454-25454/? A/DEBUG: #02 pc 0001d8a5 /system/lib/libc.so (raise+10)
09-07 19:27:50.064 25454-25454/? A/DEBUG: #03 pc 000193f1 /system/lib/libc.so (__libc_android_abort+34)
09-07 19:27:50.064 25454-25454/? A/DEBUG: #04 pc 00017034 /system/lib/libc.so (abort+4)
09-07 19:27:50.064 25454-25454/? A/DEBUG: #05 pc 001309af /data/app/?-1/lib/arm/libpjsua2.so (_ZN9__gnu_cxx27__verbose_terminate_handlerEv+226)
09-07 19:27:50.064 25454-25454/? A/DEBUG: #06 pc 0012b665 /data/app/?-1/lib/arm/libpjsua2.so (_ZN10__cxxabiv111__terminateEPFvvE+4)
09-07 19:27:50.064 25454-25454/? A/DEBUG: #07 pc 0012b6d9 /data/app/?-1/lib/arm/libpjsua2.so (_ZSt9terminatev+8)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #08 pc 0012b7fd /data/app/?-1/lib/arm/libpjsua2.so (__cxa_throw+120)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #09 pc 0006cfe3 /data/app/?-1/lib/arm/libpjsua2.so (_ZN20SwigDirector_Account10onRegStateERN2pj15OnRegStateParamE+186)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #10 pc 00091a53 /data/app/?-1/lib/arm/libpjsua2.so (_ZN2pj8Endpoint13on_reg_state2EiP14pjsua_reg_info+110)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #11 pc 000a8771 /data/app/?-1/lib/arm/libpjsua2.so (regc_cb+1092)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #12 pc 000c0c81 /data/app/?-1/lib/arm/libpjsua2.so (regc_tsx_callback+1368)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #13 pc 000d5223 /data/app/?-1/lib/arm/libpjsua2.so (tsx_set_state+190)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #14 pc 000d607b /data/app/?-1/lib/arm/libpjsua2.so (send_msg_callback+446)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #15 pc 000cdb09 /data/app/?-1/lib/arm/libpjsua2.so (stateless_send_transport_cb+68)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #16 pc 000d0291 /data/app/?-1/lib/arm/libpjsua2.so (transport_send_callback+20)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #17 pc 000d21fb /data/app/?-1/lib/arm/libpjsua2.so (on_data_sent+38)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #18 pc 000d24fb /data/app/?-1/lib/arm/libpjsua2.so (on_connect_complete+82)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #19 pc 00122e3d /data/app/?-1/lib/arm/libpjsua2.so (ioqueue_dispatch_write_event+124)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #20 pc 00123c03 /data/app/?-1/lib/arm/libpjsua2.so (pj_ioqueue_poll+462)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #21 pc 000cd519 /data/app/?-1/lib/arm/libpjsua2.so (pjsip_endpt_handle_events2+90)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #22 pc 000ae505 /data/app/?-1/lib/arm/libpjsua2.so (pjsua_handle_events+32)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #23 pc 000ae529 /data/app/?-1/lib/arm/libpjsua2.so (worker_thread+16)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #24 pc 0012453d /data/app/?-1/lib/arm/libpjsua2.so (thread_main+40)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #25 pc 000470b3 /system/lib/libc.so (_ZL15__pthread_startPv+22)
09-07 19:27:50.065 25454-25454/? A/DEBUG: #26 pc 00019e3d /system/lib/libc.so (__start_thread+6)
如您所见，库在收到拒绝连接"错误并计划下一次重试(根据日志)后立即崩溃. 因此，我们进行了测试以证明该建议-我们将SIP服务器配置为拒绝任何连接，然后我们就知道了！ 因此，当出现连接错误时就会出现问题.
As you see, the library crashed immediately after receiving "Connection refused" error and planing the next retry (according to logs). So we made a test to prove the suggestion - we configured the SIP server to refuse any connections, and we got it! So the problem appeared when there is a connection error.
牢记这一点，我在 onRegState()回调中放置了一个断点.我再次尝试并击中断点，然后释放它，应用崩溃了.然后，我注释掉了该方法中的代码，然后再次尝试:击中断点，释放并... 不崩溃 这很奇怪，因为我的逻辑很轻松，并且对Pjsip本身什么也不做.
Keeping this in mind I placed a break point in the onRegState() callback. I tried again and got the break point hit, then I released it and app crashed. Then I commented out my code in the method, and tried again: break point hit, release and... NO CRASH It was strange, because my logic on that was pretty light and doing nothing with Pjsip itself.
然后，我放置了一个日志，以查明回调正在运行哪个线程，并且...感到惊讶！
Then I put a log to find out which thread the callback is running and... surprise!
答案(TL; DR)(mb原因不正确)
onRegState()回调方法在其内部某个地方创建的Pjsip线程之一中运行. 因此，一旦我通过将代码调用发布到我的工作线程中替换了对此处代码的调用，崩溃便消失了.看起来Pjsip正在等待所有回调方法尽早返回，并不意味着它们会延迟任何时间.
The onRegState() callback method runs in one of the Pjsip threads created by it somewhere internally. So once I replaced the call to my code here by posting it to my worker thread crashes disappeared. Looks like Pjsip is waiting for all it's callback method to return early and doesn't imply them to delay for any amount of time.
因此，我建议使用 Runnable 从那里包装对您代码的调用，并将其发布到 Handler (无论是UI线程还是您自己的工作线程)，然后崩溃将不复存在. 我还没有测试其他Pjsip回调线程-它们还是内部Pjsip线程吗?但是我很确定它们是这样，并且计划以相同的方式( Runnable ->发布到 Hadler )将来自所有Pjsip回调的所有代码包装到我的代码中
So I suggest to wrap calls to your code from there with Runnable and post it to a Handler (no matter to UI thread or to your own worker thread) and crashes will be gone. I haven't tested other Pjsip callbacks threads - are they also internal Pjsip threads or not? But I'm pretty sure they are and plan to wrap all calls to my code from any Pjsip callback the same way (Runnable -> post to Hadler)
因此，您的代码可能看起来像这样来解决该问题:
So your code may looks like this to overcome the problem:
@Override
public void onRegState(OnRegStateParam prm) {
Log.d(TAG, "onRegState...");
final int stateCode = prm.getCode().swigValue();
mHandler.post(new Runnable() {
@Override
public void run() {
PresenceStatus prsenStatus = new PresenceStatus();
if (stateCode /100 == 2) {
Log.d(TAG, "Going online!");
listener.onLogIn(true);
prsenStatus.setStatus(pjsua_buddy_status.PJSUA_BUDDY_STATUS_ONLINE);
} else {
Log.d(TAG, "Going offline!");
listener.onLogIn(false);
prsenStatus.setStatus(pjsua_buddy_status.PJSUA_BUDDY_STATUS_OFFLINE);
}
try {
sipAccount.setOnlineStatus(prsenStatus);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
其中 mHandler 是您用于在某处创建的Pjsip的线程的 Handler .或者您可以使用任何其他解决方案，将这种方法从任何工作分担给线程...
where mHandler is your Handler of the thread you use to work with Pjsip created somewhere. Or you may use any other solution that offloads this method from any work to your thread...
更新
- 我检查了一下，发现所有Pjsip回调都在由库创建的线程中运行.除了第一次呼叫 Call 的 onCallState(OnCallStateParam prm).第一次在创建 Call 的同一个线程中调用它，但是每次Pjsip创建的不同线程都进行下一次调用，每次创建新线程.
- 我发现以前我为注册失败抛出了一个新的 RuntimeException .因此，实际上，此崩溃是由此回调执行的代码中意外的异常导致的.
- I have checked and found that all Pjsip callbacks run in threads cretead by library. Except the first call to the onCallState(OnCallStateParam prm) of the Call. First time it is called in the same thread where the Call was created, but next calls happen on different threads created by the Pjsip, each time a new thread.
- I have found that previously I threw a new RuntimeException for registration failure. So actually this crash is a result of unexpected Exception in your code executed by this callback.
因此Pjsip线程中的 Exception 导致本机库崩溃.
So Exception in the Pjsip thread leads to the native library crash.
更新后的答案
我得出结论，当回调(在回调线程中)执行的代码中出现意外的 Exception 时，库崩溃.
I conclude that the library crashes when there was an unexpected Exception in the code executed by the callback (in the callback thread).
但我建议使用相同的解决方案:
But I recommend the same solution:
不要在回调中运行任何业务逻辑，而是将其发布到您的 Thread
Don't run any business-logic in the callback, post it to your Thread
因此，您将同时做到:
- 保护库回调踏板与逻辑线程(UI，工作器等)之间的竞争状态
- 并防止此类错误在库中崩溃，并获得良好的旧Java异常=)
这篇关于Pjsip在RegState回调中崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
查看全文
