實踐:信號處理關鍵部分
從我的理解,一個可能要允許代碼關鍵部分的運行,不會中斷。
可以通過阻止標準信號等中斷來實現。
衝突:
我如何能夠處理從一個關鍵部分的代碼中發生故障/標準信號。 我能想到的一個經典例子是分配內存失敗。 甚至更好,由於地址無效而無法釋放內存。 從我理解的「alloc/free」部分開始的內存操作確實屬於臨界區部分。
我有什麼企圖:
我曾嘗試搜索周圍,以及學習的信號和重入主題, 但是我偶然發現了這個矛盾。
一些輸入將是偉大的,在此先感謝。
實踐:信號處理關鍵部分
從我的理解,一個可能要允許代碼關鍵部分的運行,不會中斷。
可以通過阻止標準信號等中斷來實現。
衝突:
我如何能夠處理從一個關鍵部分的代碼中發生故障/標準信號。 我能想到的一個經典例子是分配內存失敗。 甚至更好,由於地址無效而無法釋放內存。 從我理解的「alloc/free」部分開始的內存操作確實屬於臨界區部分。
我有什麼企圖:
我曾嘗試搜索周圍,以及學習的信號和重入主題, 但是我偶然發現了這個矛盾。
一些輸入將是偉大的,在此先感謝。
POSIX信號,返回碼和異常是不同的東西。的代碼
關鍵部分不中斷
運行準確地說,臨界區是由互斥鎖把守的代碼塊。也就是說,一次只能有一個線程進入關鍵部分。
我將如何處理從關鍵部分代碼發生的故障/標準信號。我能想到的一個典型例子是分配內存失敗。
如果失敗malloc
返回NULL
,沒有信號這裏涉及。
甚至更好,由於地址無效而無法釋放內存。
這種類型的錯誤不能由代碼處理。這是一個編程錯誤,必須儘早發現並修復。發現此類錯誤的最佳工具之一是Valgrind。
因爲當你收到SIGSEGV
,SIGBUS
,SIGILL
或SIGFPE
信號,你的進程地址空間的狀態是不確定的,代碼可能會通過生成SIGSEGV
時損壞的所有進程的內存,所以恢復沒有什麼好辦法在收到此信號後,程序的正確狀態。
謝謝,我在處理標準信號時瞄準的目標是實際上將內存轉儲核心放入流中,而不是從中恢復,顯然如果軟件正朝着崩潰前進,您應該讓它崩潰。 – Illasera 2014-08-29 13:57:16
@Illasera默認情況下,這些信號會導致核心轉儲,請參見['man signal(7)'](http://man7.org/linux/man-pages/man7/signal.7.html)。您可能需要使用'ulimit -c unlimited'在'.bash_profile'中啓用核心轉儲。有關更多詳細信息,請參閱['man core(5)'](http://man7.org/linux/man-pages/man5/core.5.html)。或者使用'setrlimit(RLIMIT_CORE,...)'和'prctl(PR_SET_DUMPABLE,1,0,0,0)'以編程方式啓用核心文件。 – 2014-08-29 14:31:40
如果我在檢查一次的時候記得正確,並且現在重新檢查它,它不包括堆棧回溯以及在崩潰時使用的文件描述符,也沒有其他數據在procfs或其他查詢中填充可能希望自行執行現在的問題是,根據您的主要答案,如果在崩潰期間獲取此類數據甚至是有效的。 (我之前沒有指出它,對此很抱歉)。 – Illasera 2014-08-29 15:12:22
分配內存與信號無關。信號是由Ctrl-C或垂死的孩子引起的。 – 2014-08-29 13:38:56
分配關鍵部分之外的內存。只更新臨界區域內的指針。 – 2014-08-29 13:39:42
還是內存故障?例如。 – Illasera 2014-08-29 13:40:09