建站
咨詢
售后
建站咨詢
新聞中心
Linux 是一款非常穩(wěn)定可靠的操作系統(tǒng)，但是隨著軟件的不斷升級和各種應用程序的普及，Linux 報錯也日益常見，比如常見的 139 錯誤碼。這個錯誤通常與應用程序錯誤或者是系統(tǒng)庫錯誤有關，下面我們將對 Linux 報錯代碼 139 進行詳細解析，并提供一些修復方法。
站在用戶的角度思考問題，與客戶深入溝通，找到海珠網(wǎng)站設計與海珠網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設計與互聯(lián)網(wǎng)技術結合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站制作、成都網(wǎng)站設計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、雅安服務器托管、企業(yè)郵箱。業(yè)務覆蓋海珠地區(qū)。
Linux 報錯代碼 139 的含義
Linux 報錯代碼 139 通常表示應用程序中的段錯誤（Segmentation Fault），也就是程序試圖讀取或?qū)懭敕欠ǖ膬?nèi)存位置，導致程序崩潰。這個錯誤碼還有其他的含義，比如在某些高級語言中，它可能表示運行時錯誤。
造成這個錯誤的原因很多，可能是代碼中的指針錯誤、數(shù)組越界、緩沖區(qū)溢出、堆棧溢出等。當程序試圖訪問無效的內(nèi)存地址時，內(nèi)核會檢測到這個情況，并發(fā)送一個信號給應用程序，告訴它出現(xiàn)了段錯誤。然后應用程序?qū)Ｖ共⑼顺觥?/p>
常見的修復方法
雖然 Linux 報錯代碼 139 可能是一個非常惱人的問題，但是通常來說這個問題是可以解決的。下面我們提供一些常見的修復方法。
1. 檢查代碼
我們需要檢查應用程序的代碼。如果應用程序在使用指針時沒有正確檢查是否空，或者在使用數(shù)組時沒有檢查數(shù)組下標是否越界，這可能會導致 Linux 報錯代碼 139。因此，我們需要仔細檢查代碼并修復潛在的錯誤。
2. 檢查系統(tǒng)庫
有時候，Linux 報錯代碼 139 可能是由于系統(tǒng)庫中的錯誤引起的。這時候，我們需要檢查系統(tǒng)庫是否正確安裝、更新和配置。如果系統(tǒng)庫存在問題，可以嘗試重新安裝、更新或者更改配置來解決問題。
3. 調(diào)試應用程序
在調(diào)試應用程序時，我們可以使用 gdb 工具來了解程序在崩潰時發(fā)生了什么。通過 gdb，我們可以查看程序狀態(tài)、變量值、堆棧信息等，找到導致 Linux 報錯代碼 139 的根本原因，并嘗試解決它。
4. 優(yōu)化編譯器選項
有時候，使用不正確的編譯選項可能會導致 Linux 報錯代碼 139。例如，過度優(yōu)化代碼可能會導致指針和數(shù)組訪問錯誤。因此，我們需要使用正確的編譯器選項來編譯應用程序。
5. 使用內(nèi)存檢測工具
我們可以使用內(nèi)存檢測工具來幫助我們找到代碼中的內(nèi)存訪問錯誤。常見的工具包括 Valgrind、Memtest86 等。這些工具可以檢測內(nèi)存訪問錯誤，并幫助我們盡早發(fā)現(xiàn)和解決這些問題。
Linux 報錯代碼 139 可能是一個非常令人沮喪的問題，但是通過一些簡單的方法，我們可以找到并解決這些問題。對于開發(fā)人員來說，請確保程序代碼沒有內(nèi)存訪問錯誤，并使用正確的編譯選項來編譯應用程序。對于系統(tǒng)管理員來說，請確保系統(tǒng)庫正確安裝、更新和配置好，并使用內(nèi)存檢測工具來幫助找到和解決內(nèi)存訪問錯誤。通過這些方法，我們可以提高 Linux 系統(tǒng)的穩(wěn)定性和可靠性，為用戶提供更好的服務。
成都網(wǎng)站建設公司-創(chuàng)新互聯(lián)為您提供網(wǎng)站建設、網(wǎng)站制作、網(wǎng)頁設計及定制高端網(wǎng)站建設服務！
關于Linux中禁用中斷和鎖定的關系問題
禁用了中斷后就不會發(fā)生搶占了，搶占是通過中斷來實現(xiàn)的。
你可以參考一下
一個硬中斷的完整處理過程（2.4.24版本） CPU做的搜余工作：
CPU收到中斷/異常信號；
CPU判斷當前CPL級別如果等于3，則導致堆棧切換3->0，堆棧切換過程：
a. CPU從當前TR指向的TSS中讀取SS0和ESP0；
b. CPU將當前的【SS:ESP】寄存器內(nèi)容臨時保存起來，假設為SSt和ESPt；
c. CPU將SS0和ESP0恢復到【SS:ESP】寄存器中；
d. CPU將在b中臨時保存的SSt和ESPt壓入當前的堆棧【SS:ESP】中世伏滾（其實就是SS0和ESP0)；
CPU判斷當前CPL級別如果等于0，則不會有2中的步驟；
CPU將EFLAGS、CS、EIP依次壓入當前的堆?！維S:ESP】中；
如果當前是異常，則CPU將異常碼error code壓入當前的堆棧【SS:ESP】中，否則會省略該步驟；
對于中斷，CPU清零當前EFLAGS->IF位，即關閉CPU中斷使能，對于異常，CPU則不會清零該位；
執(zhí)行對中斷/異常處理程序的調(diào)用；
注：對中斷/異常處理程序的要求，為了正常的從中斷/異常處理程序中返回，中斷/異常處理程序必須使用IRET指令返回，該指令會依次出棧EIP、CS和EFLAGS，比RET多一個EFLAGS，當EFLAGS恢復后，由于原來保存時IF位為1，因廳歲此這里相當于CPU中斷使能又打開了；
Linux內(nèi)核做的工作：
1. 中斷向量表–>common_interrupt：
common_interrupt:
SAVE_ALL
pushl $ret_from_intr
SYMBOL_NAME_STR(call_do_IRQ):
jmp SYMBOL_NAME_STR(do_IRQ);
SAVE_ALL保存所有CPU沒有保存的寄存器，由于do_IRQ是函數(shù)，這里直接調(diào)用jmp，（一般用call來調(diào)用函數(shù)，call會導致pushEIP，但jmp不會）這樣當do_IRQ返回調(diào)用ret（ret相當于popEIP）時，會彈出棧中最后一個元素到EIP，很顯然這里就是ret_from_intr，也就是說，從do_IRQ中返回后，會跳轉(zhuǎn)到ret_from_intr處繼續(xù)執(zhí)行；
2. 來到do_IRQ：
a. 首先給硬中斷計數(shù)加1,irq_enter(cpu, irq)也就是：++local_irq_count(cpu)；每進入一個硬中斷處理函數(shù)前，local_irq_count(cpu)計數(shù)便被加1，處理完畢后減1；
b. 如果當前設備中斷處理函數(shù)可以在中斷打開的情況下運行，則調(diào)用sti將EFLAGS.IF置位，打開硬中斷使能；
c. 調(diào)用request_irq注冊的設備硬中斷處理函數(shù)；
d. 無論EFLAGS.IF是否為0，都調(diào)用cli將EFLAGS.IF清零，將硬中斷使能關閉；
e. 給硬中斷計數(shù)減1,irq_enter(cpu, irq);該函數(shù)其實就是：–local_irq_count(cpu);
f. 如果此時有軟中斷需要運行（如在前面的硬中斷處理函數(shù)中調(diào)用__cpu_raise_softirq），則進入do_softirq中處理軟中斷，關于do_softirq中的處理步驟見3；
e. do_IRQ執(zhí)行ret，返回到ret_from_intr。
3. do_softirq：
a. 首先判斷當前是否還有沒有處理完畢的硬中斷處理程序或軟中斷處理程序，如果有，則直接退出該函數(shù)。判斷方法見附注【文（6）】。
b.將軟中斷處理計數(shù)加1，local_bh_disable()也就是local_bh_count(cpu)++；每進入do_softirq準備進行處理軟中斷前，local_bh_count(cpu)計數(shù)便被加1，軟中斷處理函數(shù)處理完畢后，在do_softirq返回前，將其值減1；
c. 無論EFLAGS.IF是否為0，都調(diào)用cli將EFLAGS.IF清零，將硬中斷使能關閉，處理些軟中斷標志位的問題，隨后調(diào)用sti將EFLAGS.IF置位，打開硬中斷使能；
d. 執(zhí)行軟中斷處理函數(shù)；
e. 調(diào)用cli將EFLAGS.IF清零，將硬中斷使能關閉，處理些軟中斷標志位的問題；
f. 將軟中斷處理計數(shù)減1，local_bh_enable()也就是local_bh_count(cpu)–；
g. 返回到2.e中；
4. ret_from_intr：
ENTRY(ret_from_intr)
GET_CURRENT(%ebx)
movl EFLAGS(%esp),%eax
movb CS(%esp),%al
testl $(VM_MASK | 3),%eax
jne ret_with_reschedule
jmp restore_all
在這段代碼中，通過”testl $(VM_MASK |3),%eax”檢測中斷前夕寄存器EFLAGS的高6位和代碼段寄存器CS的內(nèi)容，來判斷中斷前夕CPU是否運行于VM86模式、用戶空間還是系統(tǒng)空間，對VM86這里不講了，但是我們知道CS更低兩位代表著中斷發(fā)生時CPU的運行級別CPL，我們知道Linux只采用兩種運行級別，系統(tǒng)為0，用戶為3，所以，如果CS的更低兩位為非0，那就說明中斷發(fā)生于用戶空間。如果中斷發(fā)生于系統(tǒng)空間，控制就直接轉(zhuǎn)移到restore_all，而如果發(fā)生于用戶空間，則轉(zhuǎn)移到ret_with_reschedule。在restore_all中恢復1中保存的寄存器，隨后調(diào)用iret恢復EIP、CS、EFLAGS返回到中斷發(fā)生時的狀態(tài)。
5. ret_with_reschedule：
a. 如果發(fā)現(xiàn)當前進程的need_resched==1，則會調(diào)用schedule；
b. 如果發(fā)現(xiàn)還有待需要處理的軟中斷，則會調(diào)用do_softirq；
說明：能夠走到ret_with_reschedule處，從4中可知，該中斷前一定位于用戶層，而且不可能有可中斷的硬中斷或軟中斷沒有執(zhí)行，也就是說到達這里in_interrupt必然為0。為什么這里要說不可能有可中斷的硬中斷或軟中斷沒有執(zhí)行呢？可中斷的硬中斷或軟中斷必然是被中斷或者異常所打斷的，當后者處理完畢后，從4中可知，由于后者發(fā)生前位于內(nèi)核態(tài)（也就是可中斷的硬中斷或軟中斷處理過程中的那個點），故控制就直接轉(zhuǎn)移到restore_all，即返回到了可中斷的硬中斷或軟中斷被打斷時的那個點，繼續(xù)處理完畢，可見，到達這里，必然不存在可中斷的硬中斷或軟中斷未被執(zhí)行。
附注：關于in_interrupt宏，也就是(local_irq_count(__cpu) +local_bh_count(__cpu) !=0)。什么情況下會導致進入do_softriq時，in_interrupt不為0呢？之一種，如果當前正在處理可中斷的硬中斷處理函數(shù)，假設此時來了另一個通道的硬中斷，將導致當前硬中斷處理函數(shù)被中斷，進入do_IRQ，隨后處理新來的硬中斷處理函數(shù)，當處理完畢后，到達do_softirq，由2中可知，此時local_irq_count(__cpu)被原先的硬中斷加1，由于其還沒有處理完畢，故–local_irq_count(cpu)還沒來得及執(zhí)行，因此local_irq_count(__cpu)>0，也就是in_interrupt！=0；第二種，如果當前正在do_softirq中處理軟中斷處理函數(shù)，現(xiàn)在來了個硬中斷，將導致當前硬中斷處理函數(shù)被中斷，進入do_IRQ，隨后處理新來的硬中斷處理函數(shù)，當處理完畢后，又來帶到了do_softirq，由3中可知，此時local_bh_count(cpu)被前一個do_softirq加1了，但是由于其是中途被中斷的，故local_bh_count(cpu)–還沒來得及執(zhí)行，因此local_bh_count(__cpu)>0，也就是in_interrupt！=0；第三種就是綜合之一種和第二種兩種情況。
首先原子操作是通過local_irq_enable()這個宏來實現(xiàn)，這個宏實現(xiàn)了硬件中斷和軟件中斷的屏蔽。這樣CPU就不能被軟件中斷，如線程搶占。而當硬件中斷產(chǎn)生時，會將其結果保存到中斷控制器的SRCPND(resource-pend)寄存器中，然后將SRCPND的內(nèi)容送去做中斷屏蔽檢測，這一工作由設置MASK寄存器伏神手相應的位完成缺嫌，如果全部屏蔽，硬件中斷就不會產(chǎn)生了。當然了，每種處理瞎孝器都有自己的中斷處理方法，通常的流程是這樣。
關于linux error code 139的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。
創(chuàng)新互聯(lián)（cdcxhl.com）提供穩(wěn)定的云服務器,香港云服務器,BGP云服務器,雙線云服務器,高防云服務器,成都云服務器,服務器托管。精選鉅惠，歡迎咨詢：028-86922220。
網(wǎng)頁名稱：Linux報錯代碼139解析與修復方法(linuxerrorcode139)
文章起源：http://www.dlmjj.cn/article/cdihhcp.html
