两则glib使用技巧

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。