兩則glib使用技巧

作者****：李先靜 1.

用valgrind檢測glib的記憶體錯誤。

前段時間我們發現乙個daemon總是隨機的crash，對於這種隨機的crash的bug，我們自然會想到是記憶體越界問題引起的。但是用valgrind檢測卻沒有發現任何錯誤，那部分**比較複雜，結果花了幾天也沒有發現任何線索。後來，我想起glib裡有自己的記憶體管理機制，通過glib分配的記憶體是glib自己管理的，valgrind只是過載glibc的記憶體管理函式，它根本不知道glib的存在，因此glib所分配的記憶體發生越界，valgrind自然是無法知道的。

怎麼辦呢？我想最簡單的辦法就是，在除錯版本中，讓glib直接呼叫glibc的函式，而不要自己管理。我看了一下glib的**，想通過條件編譯來做到這一點，結果發現它已經提供了繞過glib記憶體管理機制的設定，按如下方式即可繞過glib的記憶體管理機制： if

(getenv

("bypass_glib_pools"

) !=

null)

g_type_init();

g_thread_init(

null);

注意，一定要在

g_type_init之前呼叫，否則無效。呼叫

g_slice_set_config

之後，重新用valgrind執行那個程式，不到一分鐘就找到了錯誤的根源。 2.

設定glib的log級別。

glib提供了一系列的log函式，像g_message、g_critical、g_warning、g_debug和g_error等，可以根據資訊的類別呼叫不同的函式。

在我們的程式中，為了除錯方便，很多地方調了g_debug，結果程式執行起來後，終端上的資訊列印得眼花繚亂，不但影響效能，而且把真正有用的資訊淹沒掉了。

glib既然提供了log級別，自然可以按log級別加以過濾。不過稍微有點麻煩，可以按下列方式實現：

static

void

dummy_log

(const

gchar *

log_domain

, gloglevelflags

log_level

, const

gchar *

message

, gpointer

user_data)

void

set_log_level

(const

char

* progname)

} g_free(

log_level_env_name

); return

; }

通過設定」

可執行檔名(

大寫)_log_level

」環境變數，可以過濾不同嚴重程度的log資訊，其取值為1-7，值越大，列印的資訊越多。

~~end~~

兩則glib使用技巧

man 使用技巧兩則

DirectFB兩則技巧

兩則C語言技巧

兩則glib使用技巧

man 使用技巧兩則

DirectFB兩則技巧

兩則C語言技巧

相關推薦