Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

章 4. 編譯器與工具

tail --follow 現在已能正常搭配 Veritas Clustered 檔案系統(VXFS)上的檔案使用

Veritas Clustered file system(VXFS)是個遠端檔案系統,對於遠端檔案系統,tail 無法使用 '--follow' 模式的 'inotify' 功能。Veritas Clustered 檔案系統現在已被新增至遠端檔案系統清單中,並且使用了輪詢模式來取代 'inotify'。現在即使用於 VXFS 上的檔案,tail --follow 也可正常運作。

dd 指令現在已能顯示傳輸進度

用來以位元組為單位複製檔案的 dd 指令現在已提供了 'status=progress' 選項來顯示傳輸進度。這對於傳輸大型檔案來說特別有幫助,因為它允許使用者估計剩餘的時間,並偵測傳輸上的潛在問題。

改善了 libcurl 的等待時間

libcurl 函式庫對於無有效檔案描述元的動作使用了不必要的長時間阻斷延遲,儘管是較短的作業亦然。這代表某些動作(例如使用 /etc/hosts 來解析主機名稱)會花上一段長時間來完成。libcurl 中的阻斷碼(blocking code)現在已經過修正,而初始延遲已縮短,並且會逐漸增長直到一項事件發生。高速的 libcurl 作業現在已能更快速完成。

libcurl 函式庫現在會實作一個非阻塞式的 SSL handshake

先前,libcurl 函式庫並不會實作一項非阻斷式的 SSL handshake,這對基於 libcurl multi API 的應用程式的效能會產生負面影響。若要解決這項問題,非阻斷式的 SSL handshake 已實作於 libcurl 中,並且 libcurl multi API 現在在無法讀取來自於基礎網路 socket 的資料、或無法將資料寫入基礎網路 socket 時,便會即刻將控制權傳回至應用程式。

IBM Power Systems 上的 GDB 現在存取符號表時已不會失效

先前,64 位元 IBM Power Systems 上的 GDB 會錯誤取消一項重要變數的分配(這項變數提供了將被除錯的二進位檔的符號表),這會造成 GDB 在嘗試存取該符號表時產生區段錯誤(segmentation fault)。為了解決這項問題,這項特定變數已被設為永續性,而 GDB 現在已能在除錯 session 進行時存取必要的資訊,並且不會讀取到無效的記憶體區域。

nscd 已更新並會自動載入配置資料

這項 Name Server Caching Daemon(nscd)更新為 nscd 配置檔案新增了基於 inotify 的監控系統和基於數據的備份監控,如此一來 nscd 現在便能正確偵測到其配置上的變更並載入資料。這能避免 nscd 回傳資料失效(stale data)。

dlopen 函式庫功能已不會在遞迴調用的情況下當機

先前,dlopen 函式庫功能中的一項缺失會造成對於這項功能的遞迴調用當機或退出並回傳函式庫判斷提示。若使用者提供的 malloc 實作調用 dlopen 的話,遞迴調用便可能會成功。
這項實作現在已可重新進入,並且遞迴調用已不再會當機或退出並回傳判斷提示。

operf 工具現在已能辨識靜態的巨型分頁的識別碼

先前,當在巨型分頁已啟用的情況下分析 Java just-in-time(JIT)所編譯的程式碼之效能時,OProfile 的 operf 指令會將大量事件範本紀錄到匿名記憶體中(anon_hugepage 裡)而非至適當的 Java method 中。透過這項更新,operf 能辨識靜態巨型分頁的識別碼,並在使用靜態分配的巨型分頁時,正確將範本映射至 Java method 上。

rsync -X 指令現在已能正確運作

先前,rsync 工具會在設定安全性屬性之後(而不是之前)改變檔案擁有權。因為如此,目標的安全性屬性會遺失,而在特定情況下執行 rsync -X 指令會無法正常運作。透過了這項更新,作業的順序已被調換,並且 rsync 現在會在設定安全性屬性之前更改擁有權。因此,安全性屬性會在先前描述的情況下,按照預期地顯示。

Subversion 可執行檔現在已透過完整的 RELRO 資料建置

透過 subversion 套件供應的可執行檔現在已組建了完整唯讀的重定位資料(RELRO),這針對部分類型的記憶體損毀攻擊提供了相關保護。因此,未來就算發現了漏洞,要成功入侵 Subversion 也會相當困難。

TCL 中的執行緒延伸現在已能正常運作

先前,工具指令語言(Tool Command Language,TCL)中的執行緒支援並未最佳化實作。若 fork() 調用與在 TCL 解譯器中啟用的執行緒延伸(thread extension)搭配使用的話,這項程序可能會停止反應。因此,TCL 解譯器和 TK 應用程式先前是在停用執行緒延伸的情況下提供的。然而也因為如此,先前依賴搭配了執行緒的 TCL 或 TK 的第三方應用程式無法正常運作。目前已有一項修補程式被實作來修正這項錯誤,並且 TCL 和 TK 現在就預設值已啟用了執行緒延伸。