問題
崩潰清單中顯示的崩潰與已看到的崩潰相同的原因是什麼？
答案
分析以下兩個sessmgr進程崩潰時，您可能會認為它們是相同的，並想知道系統為什麼將它們分別列在崩潰清單中。在仔細觀察時，請注意show crash number X輸出最左側的列中的地址略有不同，這是代碼中的點，在該點上，同一行上的函式呼叫上面列出的函式(本例中為snx_hgwdrv_send_add_sub_session())。
******** show crash list *******
Friday October 03 18:25:28 UTC 2014
== ==== ======= ========== =========== ================
# Time Process Card/CPU/ SW HW_SER_NUM
PID VERSION SMC / Crash Card
== ==== ======= ========== =========== ================
1 2013-Nov-30+05:08:15 sessmgr 07/0/04317 14.1(50455) SAD160200KX/PLB31103947
2 2014-Jun-06+16:45:44 sessmgr 05/0/06002 15.0(53417) SAD160200KX/PLB37108248
3 2014-Oct-02+08:08:03 sessmgr 15/0/06059 16.1(55894) SAD160200KX/PLB42100206
4 2014-Oct-03+03:02:00 sessmgr 02/0/05979 16.1(55894) SAD160200KX/PLB38108892
Total Crashes : 12
********************* CRASH #03 ***********************
SW Version : 16.1(55894)
Similar Crash Count : 1
Time of First Crash : 2014-Oct-02+08:08:03
Fatal Signal 11: Segmentation fault
PC: [0534bf6d/X] sessmgr_imsa_update_ip_addr()
Faulty address: (nil)
Signal from: kernel
Signal detail: address not mapped to object
Process: card=15 cpu=0 arch=X pid=6059 cpu=~0% argv0=sessmgr
Crash time: 2014-Oct-02+08:08:03 UTC
Recent errno: 11 Resource temporarily unavailable
Stack (64280@0xfffee000):
[0534bf6d/X] sessmgr_imsa_update_ip_addr() sp=0xfffee7d8
[0365f41d/X] sessmgr_mag_handle_add_sub_session() sp=0xfffee928
[036f3a66/X] smgr_fsm_state_connected() sp=0xffffaff8
[03681397/X] smgr_callline_fsm() sp=0xffffb098
[05d8089b/X] sessmgr_app_svr_event_control_dispatch() sp=0xffffb628
[0461986b/X] snx_hsgwdrv_send_add_sub_session() sp=0xffffbba8
[0461dfa6/X] snx_hsgwdrv_fsm() sp=0xffffbd68
[04621cba/X] snx_hsgwdrv_event_control_dispatch() sp=0xffffbdf8
[046032b6/X] snx_pppdrv_notify_vsncp_up() sp=0xffffbe28
[046036ac/X] snx_pppdrv_fsm_state_connected() sp=0xffffbe68
[0460446a/X] snx_pppdrv_fsm() sp=0xffffbfe8
[04608e0a/X] mlppp_event_indication() sp=0xffffc328
[0514d1ae/X] VSNCPNotify() sp=0xffffc388
[0515e88d/X] NCPRunStateActions() sp=0xffffc3e8
[0515ae53/X] ProcessConfigData() sp=0xffffc488
[0515b9ec/X] ProcessNCP() sp=0xffffc4b8
[05144931/X] MLPSwitch() sp=0xffffc558
[05167c5c/X] PPPSwitch() sp=0xffffc768
[05e47033/X] DoSomethingWithData.isra.149() sp=0xffffcc78
[05e5a1ea/X] sessmgr_med_rp_a10_data_receive() sp=0xffffd3f8
[0600880d/X] sessmgr_med_data_receive() sp=0xffffd598
[0ac565ac/X] sn_epoll_run_events() sp=0xffffd5e8
[0ac5aca8/X] sn_loop_run() sp=0xffffda98
[0a9fd96d/X] main() sp=0xffffdb08
********************* CRASH #04 ***********************
SW Version : 16.1(55894)
Similar Crash Count : 9
Time of First Crash : 2014-Oct-02+07:31:35
Fatal Signal 11: Segmentation fault
PC: [0534bf6d/X] sessmgr_imsa_update_ip_addr()
Faulty address: (nil)
Signal from: kernel
Signal detail: address not mapped to object
Process: card=2 cpu=0 arch=X pid=5979 cpu=~4% argv0=sessmgr
Crash time: 2014-Oct-03+03:02:00 UTC
Recent errno: 11 Resource temporarily unavailable
Stack (64280@0xfffee000):
[0534bf6d/X] sessmgr_imsa_update_ip_addr() sp=0xfffee7d8
[0365f41d/X] sessmgr_mag_handle_add_sub_session() sp=0xfffee928
[036f3a66/X] smgr_fsm_state_connected() sp=0xffffaff8
[03681397/X] smgr_callline_fsm() sp=0xffffb098
[05d8089b/X] sessmgr_app_svr_event_control_dispatch() sp=0xffffb628
[0461986b/X] snx_hsgwdrv_send_add_sub_session() sp=0xffffbba8
[0461dd33/X] snx_hsgwdrv_fsm() sp=0xffffbd68
[04621cba/X] snx_hsgwdrv_event_control_dispatch() sp=0xffffbdf8
[046032b6/X] snx_pppdrv_notify_vsncp_up() sp=0xffffbe28
[046036ac/X] snx_pppdrv_fsm_state_connected() sp=0xffffbe68
[0460446a/X] snx_pppdrv_fsm() sp=0xffffbfe8
[04608e0a/X] mlppp_event_indication() sp=0xffffc328
[0514d1ae/X] VSNCPNotify() sp=0xffffc388
[0515e88d/X] NCPRunStateActions() sp=0xffffc3e8
[0515ae53/X] ProcessConfigData() sp=0xffffc488
[0515b9ec/X] ProcessNCP() sp=0xffffc4b8
[05144931/X] MLPSwitch() sp=0xffffc558
[05167c5c/X] PPPSwitch() sp=0xffffc768
[05e47033/X] DoSomethingWithData.isra.149() sp=0xffffcc78
[05e5a1ea/X] sessmgr_med_rp_a10_data_receive() sp=0xffffd3f8
[0600880d/X] sessmgr_med_data_receive() sp=0xffffd598
[0ac565ac/X] sn_epoll_run_events() sp=0xffffd5e8
[0ac5aca8/X] sn_loop_run() sp=0xffffda98
[0a9fd96d/X] main() sp=0xffffdb08
這裡的一點是，由於函式呼叫是從代碼的不同位置發出的，因此這些崩潰被列為單獨的崩潰。
在這些情況下，請與Cisco建立案例，以確認此類情形下崩潰的根本原因是否相同，這僅僅是因為不同的代碼流需要單獨的修復。
意見