两则glib使用技巧
转载时请注明出处和作者联系方式：http://blog.csdn.net/absurd
作者联系方式：李先静 <xianjimli at hotmail dot com>
更新时间：2007-7-2
glib是我们平台的基石，几乎任何函数库，任何应用程序，以及任何daemon服务进程，都大量使用glib提供的函数。glib在我们平台中的地位有如STL在C++中的地位一样，熟练使用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_slice_set_config(G_SLICE_CONFIG_ALWAYS_MALLOC, TRUE); }
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) { return; }
void set_log_level(const char* progname) { char* basename = strrchr(progname, '/'); char* log_level_env_name = NULL; char* log_level_evn_value = NULL;
basename = basename != NULL ? basename+1 : (char*)progname;
log_level_env_name = g_strdup_printf("%s_LOG_LEVEL", basename); log_level_evn_value = getenv(g_strup(log_level_env_name));
if(log_level_evn_value != NULL) { unsigned int i = 1 << (~G_LOG_LEVEL_MASK); unsigned int max_log_level = atoi(log_level_evn_value); unsigned int log_level = 0;
for(; i > max_log_level; i--) { log_level = 1 << i; g_log_set_handler(NULL, (GLogLevelFlags)log_level, dummy_log, NULL); } }
g_free(log_level_env_name);
return; }
|
通过设置 ”可执行文件名(大写)_LOG_LEVEL”环境变量，可以过滤不同严重程度的LOG信息，其取值为1-7，值越大，打印的信息越多。
~~end~~
再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow