分享一種你可能不知道的bug定位方法

運(yùn)行測(cè)試程序生成core文件：

后臺(tái)進(jìn)程如何生成core文件？

后臺(tái)程序生成core文件的方式與前臺(tái)程序不一樣。這我也是前幾天才知道的，我們?cè)O(shè)備上的程序設(shè)置為開(kāi)機(jī)自啟動(dòng)運(yùn)行于后臺(tái)，程序崩潰時(shí)，竟然沒(méi)有生成core文件。后來(lái)查了些資料才知道后臺(tái)程序打開(kāi)core文件的方式不同。

后臺(tái)進(jìn)程：后臺(tái)進(jìn)程又叫守護(hù)進(jìn)程，是運(yùn)行在系統(tǒng)后臺(tái)的一種特殊進(jìn)程，它獨(dú)立于控制終端并且周期性地執(zhí)行某種任務(wù)或等待處理某些發(fā)生的事件，后臺(tái)進(jìn)程最大的特點(diǎn)就是不受終端控制。一般用作系統(tǒng)服務(wù)，比如日志管理進(jìn)程rsyslogd，數(shù)據(jù)庫(kù)服務(wù)myspld等，當(dāng)然也有一些用戶程序因需要被放在后臺(tái)運(yùn)行，一般被放在/etc/ini.d/文件夾中設(shè)置開(kāi)機(jī)自啟動(dòng)。

ulimit命令是有作用范圍的，ulimit限制的是當(dāng)前shell進(jìn)程以及其派生的子進(jìn)程，所以通過(guò)ulimit修改coresize只是針對(duì)在當(dāng)前shell下啟動(dòng)的子進(jìn)程，而不能影響其他shell下啟動(dòng)的進(jìn)程。

所以當(dāng)我們配置完成生成core dump的參數(shù)后，在當(dāng)前shell直接執(zhí)行的進(jìn)程發(fā)生崩潰時(shí)可以正常生成core，而后臺(tái)開(kāi)機(jī)自啟動(dòng)的程序則無(wú)法生成，而實(shí)際總，嵌入式應(yīng)用程序一般都是開(kāi)機(jī)自啟動(dòng)的，并且發(fā)送崩潰的時(shí)機(jī)也是不可預(yù)測(cè)的，那么使用這種方式就不能正確的去捕捉coredump文件了。

后臺(tái)進(jìn)程要生成core dump文件需在進(jìn)程代碼中開(kāi)啟core dump功能，如：

左右滑動(dòng)查看全部代碼>>>

// 公眾號(hào)：嵌入式大雜燴 #include  #include  #include  #include  #define SHELL_CMD_CONF_CORE_FILE "echo /var/core-%e-%p-%t > /proc/sys/kernel/core_pattern" #define SHELL_CMD_DEL_CORE_FILE "rm -f /var/core*" static int enable_core_dump(void) { int ret = -1; int resource = RLIMIT_CORE; struct rlimit rlim; rlim.rlim_cur = 1 ? RLIM_INFINITY : 0;
    rlim.rlim_max = 1 ? RLIM_INFINITY : 0;

    system(SHELL_CMD_DEL_CORE_FILE); if (0 != setrlimit(resource, &rlim))
    { printf("setrlimit error!\n"); return -1;
    } else {
        system(SHELL_CMD_CONF_CORE_FILE); printf("SHELL_CMD_CONF_CORE_FILE\n"); return 0;
    } return ret;
} int main(int argc, char **argv) {
    enable_core_dump(); printf("==================segmentation fault test==================\n"); int *p = NULL;
    *p = 1234; return 0;
}

#!/bin/sh cd /home
./test