yager0203的专栏

最近项目中遇到进程core, 然后测试报了5次多了，每次去看core，都是问号。so search path, sysroot都配好了，依赖的库的symbol也都load成功了，但就都是问号。和旁边开发对了一下。他的core都能看到，我的core都看不到。后面他意识到他的core都是在主线程中生成的。我的core有线程信息，是在子线程中生成的。测试一下，发现，果然子线程中的core，无法捕获调用函数栈信息。于是，发现目前系统中启动的dumper是加了 -t 参数的。虽然介绍 -t 是捕获出问题的线程。

找到交叉编译链目录下面的交叉调试 gdb 工具获取 sysroot启动交叉调试gdb工具，通过 set sysroot，设置上面的sysroot目录，可以用“:”设置多个sysroot路径gdb环境下(gdb) file bin(gdb) target qnx 192.168.110.110:8888(gdb) attach PID(gdb) info sharedlibraries如果有so文件没有成功load symbol,则找到对应so,集中到某个目录，添加 solib-sear.

gdb调试core环境配置启动gdb调试bin和core~/PATH/TO/CROSS/COMPILE/TOOLCHAINS$ ./A_platform-aarch64-gdb BIN_FILE CORE-FILE提示so找不到，需要设置so search path;使用:set solib-search-path /PATH/TO/CROSS/COMPILE/TOOLCHAINS/SYSROOT/:/SOME/SELF/COLLECTED/SO/LIBS/未load symbol的

先有利器，才好干活通过pidin加参数 %B,可以看到当前进程的各个线程的STATE,例如：NANOSLEEP， SEM， JOIN，SEND，REPLY, RECEIVE, MUTEX, CONDVAR, 等等。QNX系统好一点的是，能够标明线程被锁住的mutex的地址，mutex隶属的线程，被锁住的次数。还能标明自线程REPLY、SEND等STATE下，所依赖的对方线程号。本次问题出现在MessageQueue类中的 pushMessage 和 handleMessage 两个方法公用一把锁

近期一个应用程序出现32k/4~5s的内存持续泄露。排查思路:在从业务链路上，从上游到下游，梳理数据流通路。在其数据收发的几个类的几个方法上，通过函数重写，添加hack函数（不做业务处理），分段查看泄露情况。在proc目录下，查看进程的mappings信息。统计当中{heap},{stack},发现{heap}是有缓慢增加的；其他段是维持固定的。通过其他demo应用，进行交叉测试，发现demo没有泄露。验证了依赖的三方库，通信库，没有泄露。整个工程当中搜索 new, malloc

在使用 dbus时，bus type 是system, dbus-daemon 也是以–system 模式拉起的。运行某个客户端，向dbus 建立链接，并输出bus name 时，出现如下错误：org.freedesktop.DBus.Error.AccessDenied修改system.conf中如下部分<!-- Holes must be punched in service co...

scanf函数，给数值型数组赋值时只能用 for 循环一个一个地赋值，给字符型数组赋值可以整体赋值输入字符型数据时，系统会自动在最后添加结束标志符 ‘\0’系统会将空格，作为输入字符之间的分隔符例如，通过scanf读入一个数值型数组： int n = 0; int *a = NULL; while (n < 1) { print...

libuv是最初为NodeJS编写的跨平台支持库。 它围绕事件驱动的异步I/O模型进行设计。该库提供的不仅仅是在不同的I/O轮询机制上的简单抽象：“句柄”和“流”为套接字和其他实体提供了高级抽象; 还提供了跨平台文件I/O和线程功能。深入的了解，可以扒libuv官网libuv为用户提供了2个与事件循环相结合的抽象：句柄和请求。句柄表示能够在活动时执行某些操作的长寿命对象。请求代表（通常）短暂的操作。

git

关于js的代码缓存