Kernel oops when remounting ubifs as read/write

kernel oops when remounting ubifs as read/write

ubi文件系统第一次启动uboot通过ro加载,如果进行remount会导致crc校验出错。解决方案是uboot先用rw加载,然后再通过mount -o 'remount,ro'命令修改为ro

按这个分析应该是内核的bug, 目前使用的内核是3.几的

drop caches

echo 1 >> /proc/sys/vm/drop_caches

error c2332 struct 缺少标记名

error c2332 struct 缺少标记名 变量名和关键字冲突了。这次是遇到的是interface在msvc中冲突了。。。可是c++没有interface这个关键字

https://stackoverflow.com/questions/25234203/what-is-the-interface-keyword-in-msvc

Microsoft has some compiler-specific extensions like the one you linked but interface shouldn't be a native C++ compiler-specific keyword but rather a define which substitutes something (in BaseTyps.h it used to be defined as follows)

define interface struct

Link here If you want to verify this do a grep for such a definition and you should find something similar.

References: http://social.msdn.microsoft.com/forums//vstudio/en-US/06bf1dea-1d20-4ec3-b9a1-3d673d7fcd8d/what-is-the-interface-keyword-in-native-c

qprocess::execute执行date命令失败

但是自己通过命令行可以执行,通过strace跟踪系统调用:

strace -f -F -p 980

发现:

execve("/dymind/lib/cups/sbin/date", ["date", "-s", "2024-09-15 17:12:37"], [/* 26 vars */] <u <... execve resumed> )  = -1 EIO (Input/output error)

所以认为是磁盘损坏导致的。因为损坏导至dymind/lib/cups/sbin这个目录无法读取,所以system调用直接返回失败了,没有做更多的偿试。

一种定位内存泄漏方法:

内存泄漏肯定是堆上的内存,那么我们找到进程的heap内存区,然把这块内存通过gdb dump到 文件,然后在这个文 件中查找出现次数最多的文本。

$ grep heap /proc/1131/maps
00c7d000-00d94000 rw-p 00000000 00:00 0         [heap]
dump binary memory /tmp/heap.bin 0x00c7d000 0x00d94000

这种方法可以定位内存中有一致的字符串的情况。 在分析dbus的内存泄漏时,使用这种方法, 发现内存中出现了大量的wifi搜过结果。 确定了是dbus模块内存泄漏,通过查看代码发现一处dbus缺少endarray调用,修改后内存正常。