signal 7 (SIGBUS), code 2 (BUS_ADRERR) #204

buptlingfeng · 2017-04-12T04:01:15Z

线上测试的时候发现 void LogBuffer::Flush(AutoBuffer& _buff) 调用 void LogBuffer::Clear()的时候出现上述的错误，具体抛错的地方是在执行memset(buff.Ptr(), 0, buff.MaxLength());的时候出现的

garryyan · 2017-04-12T08:00:07Z

什么机型什么操作系统，是否必现

buptlingfeng · 2017-04-12T09:48:26Z

有4.4.2 5.0 5.1.1 6.0 6.0.1 不是必现的问题机型有小米 OPPO 酷派等

FelixZhang00 · 2017-05-05T09:02:28Z

同样遇到了这个错误

Hardware: DYOS;Android 4.4.4,level 19
Retrace CallStack: 
SIGBUS(BUS_ADRERR): 
#00  pc 00022098  /system/lib/libc.so (__memcpy_base+180) [armeabi-v7a::2a574c1625dbbc6f3e56834c39beb987]
#01  pc 00004c04  /system/lib/libz.so (deflate+924) [armeabi-v7a::ecfc2652064aa667f591648ee13f2439]
#02  pc 0000a5fd  /data/app-lib/com.ktcp.video-2/libmarsxlog.so (_ZN9LogBuffer5WriteEPKvj+116) [armeabi-v5te::2ce0551e6f27dd8d4c02f902104d3ecf]
#03  pc 0000789d  /data/app-lib/com.ktcp.video-2/libmarsxlog.so [armeabi-v5te::2ce0551e6f27dd8d4c02f902104d3ecf]
#04  pc 00009227  /data/app-lib/com.ktcp.video-2/libmarsxlog.so [armeabi-v5te::2ce0551e6f27dd8d4c02f902104d3ecf]
#05  pc 0000a81f  /data/app-lib/com.ktcp.video-2/libmarsxlog.so (__xlogger_Write_impl+114) [armeabi-v5te::2ce0551e6f27dd8d4c02f902104d3ecf]
#06  pc 0000a959  /data/app-lib/com.ktcp.video-2/libmarsxlog.so (xlogger_Write+12) [armeabi-v5te::2ce0551e6f27dd8d4c02f902104d3ecf]
#07  pc 00006025  /data/app-lib/com.ktcp.video-2/libmarsxlog.so (Java_com_tencent_mars_xlog_Xlog_logWrite2+232) [armeabi-v5te::2ce0551e6f27dd8d4c02f902104d3ecf]
#08  pc 0001db4c  /system/lib/libdvm.so (dvmPlatformInvoke+112) [armeabi-v7a::35e0596edeee9b663f5f38f56c6af84e]

知道是什么原因吗？

garryyan · 2017-05-05T09:15:56Z

@FelixZhang00 @buptlingfeng 已经在灰度验证了，因为我这边没看到这个类型的crash，麻烦 @buptlingfeng 有进度同步一下

buptlingfeng · 2017-05-05T09:29:16Z

@FelixZhang00 <https://github.com/FelixZhang00> 你对xlog进行过定制没有？我是做过一些定制，你用的如果是原生的xlogSDK那么就是需要xlog团队仔细看下了。你是在本地测试出现的还是在线上测试发现的呢？ 2017-05-05 17:16 GMT+08:00 garryyan <[email protected]>:

…

@FelixZhang00 <https://github.com/FelixZhang00> @buptlingfeng <https://github.com/buptlingfeng> 已经在灰度验证了，因为我这边没看到这个类型的crash，麻烦 @buptlingfeng <https://github.com/buptlingfeng> 有进度同步一下 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEk0IownH2okf7EfeL9kVOLkXhMeIN-Zks5r2ujSgaJpZM4M67Sp> .

buptlingfeng · 2017-05-05T09:29:26Z

可不可以本地复现？在 2017年5月5日下午5:29，凌风 <[email protected]>写道：

…

@FelixZhang00 <https://github.com/FelixZhang00> 你对xlog进行过定制没有？我是做过一些定制，你用的如果是原生的xlogSDK那么就是需要xlog团队仔细看下了。你是在本地测试出现的还是在线上测试发现的呢？ 2017-05-05 17:16 GMT+08:00 garryyan ***@***.***>: > @FelixZhang00 <https://github.com/FelixZhang00> @buptlingfeng > <https://github.com/buptlingfeng> 已经在灰度验证了，因为我这边没看到这个类型的crash，麻烦 > @buptlingfeng <https://github.com/buptlingfeng> 有进度同步一下 > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#204 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AEk0IownH2okf7EfeL9kVOLkXhMeIN-Zks5r2ujSgaJpZM4M67Sp> > . >

FelixZhang00 · 2017-05-05T09:30:47Z

是线上测试的，本地没有出现过。

FelixZhang00 · 2017-05-05T09:31:56Z

我只修改了写日志的策略，用多个文件回滚记录。

garryyan · 2017-05-05T09:32:10Z

@FelixZhang00 改了xlog的代码？

FelixZhang00 · 2017-05-05T09:33:53Z

改了appender.cc的部分代码，和LogBuffer的__Clear方法：

void LogBuffer::__Clear() {
    //memset(buff_.Ptr(), 0, buff_.MaxLength());
    buff_.Length(0, 0);
}

FelixZhang00 · 2017-05-05T09:35:51Z

有没有可能这里__appender_async在栈上分配了较大的内存导致的？

buptlingfeng · 2017-05-05T09:38:02Z

这个在源码中只有16K 应该不至于吧我之前是改成在堆上开辟空间解决出现这个问题，现在我正在测试放在栈里边。因为他们微信使用说没遇到这个问题那就说不通了安说我们的机型覆盖不会又微信那么全，既然微信没问题所以我就怀疑是因为我这边导致的。 2017-05-05 17:35 GMT+08:00 Fei Zhang <[email protected]>:

…

有没有可能这里__appender_async <https://github.com/Tencent/mars/blob/master/mars/log/src/appender.cc#L537> 在栈上分配了较大的内存导致的？ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEk0IndXkFpznVZ18Y1pnl21CaY-jHTwks5r2u18gaJpZM4M67Sp> .

FelixZhang00 · 2017-05-05T09:43:45Z

有没有可能是同时有太多线程调用__appender_sync方法导致的？我这边先模拟试一下

buptlingfeng · 2017-05-05T09:51:14Z

这个我试过了本地也都没出现，我觉的最好是不要对xlog做任何改动，在线上run一把试试 2017-05-05 17:43 GMT+08:00 Fei Zhang <[email protected]>:

…

有没有可能是同时有太多线程调用__appender_sync方法导致的？我这边先模拟试一下 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEk0Ilol12FrRRihm3u84VZWKq4tyc6Uks5r2u9agaJpZM4M67Sp> .

FelixZhang00 · 2017-05-08T03:44:39Z

@garryyan 这个跟ndk的版本有关吗？编译xlog需要哪个ndk版本？

garryyan · 2017-05-08T06:28:53Z

@FelixZhang00 应该没什么关系，我们一般用r11c

buptlingfeng · 2017-05-08T08:56:34Z

囧我用的r13b 感觉真有可能哎，在线上一直存在这个问题 2017-05-08 14:28 GMT+08:00 garryyan <[email protected]>:

…

@FelixZhang00 <https://github.com/FelixZhang00> 应该没什么关系，我们一般用r11c — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEk0IiBCJDATHJ0pDJJPE9NGCmn-W2hpks5r3rYqgaJpZM4M67Sp> .

FelixZhang00 · 2017-05-08T09:44:07Z

BUS_ADRERR在这篇文章的解释是：

Another reason where SIGBUS can generate is explained below:
You are currently using a external I/O device by mapping the device memory
mapping into the system memory (Memory mapped I/O). You have used it. And
now, you have disconnected it gracefully. But, somehow your code is trying
to use an previouslt used address still in your code. The result in this
case will be an SIGBUS, the reason is BUS_ADRERR, "non-existent physical
address".

产生这个问题的原因可能是mmap文件被删掉了吗？
但是我把log.mmap2删掉，发现日志还是能正常写到log文件里。
然后我查看了进程的maps，发现mmap2文件被标记位deleted，这个原因我不是很清楚，希望能解释下☺

是不是说我通过shell删除log.mmap2，但是系统发现还有进程在读写它，就把它标记为deleted，其实文件还是存在的，
等进程结束再真正把这个标记的文件删掉？

如果这一点是系统来控制的，就有一定概率造成mmap文件被删掉了，但还有进程在读写它对应的内存，因为这块内存的back文件不存在了，就会造成BUS_ADRERR错误。

garryyan · 2017-05-08T09:55:58Z

这里产生这个问题的原因有两种： 1. 内存对齐的问题 2. mmap越界

你说的这个删除的问题和mmap文件无关，和linux的文件系统有关，一般来说删除一个文件只是把这一块标记为可重用，并不是彻底丢掉。在覆盖重写之前，这一块数据其实一直还在存储上，只不过是不可达的，但是如果在删除前已有文件句柄指向，即使删除文件后这个句柄依然有效。

buptlingfeng · 2017-05-08T11:08:47Z

我测试了几种case，现在只有怀疑mmap越界在 2017年5月8日下午5:56，garryyan <[email protected]>写道：

…

这里产生这个问题的原因有两种： 1. 内存对齐的问题 2. mmap越界你说的这个删除的问题和mmap文件无关，和linux的文件系统有关，一般来说删除一个文件只是把这一块标记为可重用，并不是彻底丢掉。在覆盖重写之前，这一块数据其实一直还在存储上，只不过是不可达的，但是如果在删除前已有文件句柄指向，即使删除文件后这个句柄依然有效。 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEk0ItRo8GcJ2MHIdsNM1GTXtIAmSCqRks5r3ua0gaJpZM4M67Sp> .

buptlingfeng · 2017-05-08T11:09:18Z

因为把mmap用char数组替换掉之后就完全没碰到过signal 7的错误在 2017年5月8日下午7:08，凌风 <[email protected]>写道：

…

我测试了几种case，现在只有怀疑mmap越界在 2017年5月8日下午5:56，garryyan ***@***.***>写道： > 这里产生这个问题的原因有两种： 1. 内存对齐的问题 2. mmap越界 > > 你说的这个删除的问题和mmap文件无关，和linux的文件系统有关，一般来说删除一个文件只是把这一块标记为可重用，并不是 > 彻底丢掉。在覆盖重写之前，这一块数据其实一直还在存储上，只不过是不可达的，但是如果在删除前已有文件句柄指向，即使删除文件后这个句柄依然有效。 > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#204 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AEk0ItRo8GcJ2MHIdsNM1GTXtIAmSCqRks5r3ua0gaJpZM4M67Sp> > . >

FelixZhang00 · 2017-05-08T11:12:51Z

@buptlingfeng 你的意思是这样初始化：

        char *buffer = new char[kBufferBlockLength];
        sg_log_buff = new LogBuffer(buffer, kBufferBlockLength, true);
        use_mmap = false;

buptlingfeng · 2017-05-08T11:14:59Z

是的我验证的结果是这样的，用这种方式就再没出现过signal 7的错误 2017-05-08 19:12 GMT+08:00 Fei Zhang <[email protected]>:

…

@buptlingfeng <https://github.com/buptlingfeng> 你的意思是这样初始化： char *buffer = new char[kBufferBlockLength]; sg_log_buff = new LogBuffer(buffer, kBufferBlockLength, true); use_mmap = false; — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEk0ItwV20QvPGR-7NATcHVmCBwb5OPTks5r3vi5gaJpZM4M67Sp> .

FelixZhang00 · 2017-05-08T11:27:07Z

翻过来，模拟过mmap越界操作吗？必现crash？

garryyan · 2017-06-19T04:54:49Z

这个问题已查明。
原因：mmap 文件放在sdcard目录被删除掉或者sdcard短时间内不可用导致用时crash。
暂时的解决办法：appenderOpen时第三个参数，缓存路径不要传空串，传你应用程序包目录下的文件路径，比如微信会给 /data/data/com.tencent.mm/files/xlog。这样 mmap文件会放在这个路径，测试办法：找一台root的手机，看你传的缓存目录里是否有mmap文件。
后续我会试图找到不使用缓存路径的解决办法。

注意：日志不要放在这个目录，不然就太占 data 空间了。缓存目录类似日志目录，要单独目录，防止清理逻辑误删其他文件

FelixZhang00 · 2017-06-19T04:59:15Z

我这里缓存路径是传空的，我改下试试。

FelixZhang00 · 2017-06-19T05:02:51Z

@buptlingfeng 你们也没有传缓存路径吗

buptlingfeng · 2017-06-19T05:33:02Z

也没有接下来灰度要试一下 2017-06-19 13:02 GMT+08:00 Fei Zhang <[email protected]>:

…

@buptlingfeng <https://github.com/buptlingfeng> 你们也没有传缓存路径吗 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEk0Ij_-3EJ7zF79X6DcymUYbU6KL4Pnks5sFgEBgaJpZM4M67Sp> .

logwee · 2017-07-12T14:38:51Z

我设置了缓存路劲，现在有丢日志的现象；

garryyan · 2017-07-13T01:49:05Z

@logwee 你的缓存路径设置的是什么？

logwee · 2017-07-13T02:11:49Z

@garryyan /data/data/package/files/xlog 下

garryyan · 2017-07-13T04:03:47Z

package没换成你自己的包名吗？换成自己的包名！否则怎么可能有权限

logwee · 2017-07-13T04:59:55Z

@garryyan 当然是自己的包名。
getContext().getFilesDir

garryyan · 2017-07-13T05:01:05Z

怎么看出丢日志的？

logwee · 2017-07-13T05:02:35Z

找到原因了，我的问题
启动的时候有概率没有appenderOpen，就提前去写了

garryyan added the bug label May 19, 2017

garryyan mentioned this issue Jun 19, 2017

SIGBUS(BUS_ADRERR) 崩溃 #249

Closed

garryyan added the champions label Jun 19, 2017

astrozhou pushed a commit that referenced this issue Jul 19, 2017

fix #249 #204 app crash when log mmap file is deleted.

63d87f8

garryyan closed this as completed Aug 10, 2017

BokiceLee mentioned this issue Sep 14, 2018

GetLogLen crash求助 #456

Closed

ichenhe mentioned this issue Aug 1, 2021

Android xlog 缓存文件不写移入日志目录 #960

Open

signal 7 (SIGBUS), code 2 (BUS_ADRERR) #204

signal 7 (SIGBUS), code 2 (BUS_ADRERR) #204

Comments

buptlingfeng commented Apr 12, 2017

garryyan commented Apr 12, 2017

buptlingfeng commented Apr 12, 2017

FelixZhang00 commented May 5, 2017 • edited Loading

garryyan commented May 5, 2017

buptlingfeng commented May 5, 2017 via email

buptlingfeng commented May 5, 2017 via email

FelixZhang00 commented May 5, 2017

FelixZhang00 commented May 5, 2017

garryyan commented May 5, 2017

FelixZhang00 commented May 5, 2017

FelixZhang00 commented May 5, 2017

buptlingfeng commented May 5, 2017 via email

FelixZhang00 commented May 5, 2017

buptlingfeng commented May 5, 2017 via email

FelixZhang00 commented May 8, 2017

garryyan commented May 8, 2017

buptlingfeng commented May 8, 2017 via email

FelixZhang00 commented May 8, 2017

garryyan commented May 8, 2017

buptlingfeng commented May 8, 2017 via email

buptlingfeng commented May 8, 2017 via email

FelixZhang00 commented May 8, 2017

buptlingfeng commented May 8, 2017 via email

FelixZhang00 commented May 8, 2017

garryyan commented Jun 19, 2017 • edited Loading

FelixZhang00 commented Jun 19, 2017

FelixZhang00 commented Jun 19, 2017

buptlingfeng commented Jun 19, 2017 via email

logwee commented Jul 12, 2017

garryyan commented Jul 13, 2017

logwee commented Jul 13, 2017 • edited Loading

garryyan commented Jul 13, 2017

logwee commented Jul 13, 2017 • edited Loading

garryyan commented Jul 13, 2017

logwee commented Jul 13, 2017

FelixZhang00 commented May 5, 2017 •

edited

Loading

garryyan commented Jun 19, 2017 •

edited

Loading

logwee commented Jul 13, 2017 •

edited

Loading

logwee commented Jul 13, 2017 •

edited

Loading