memcpy引起的core dump
来源:互联网 发布:duet display类似软件 编辑:程序博客网 时间:2024/04/28 21:27
在运行实验mapcg的kmeans程序时,当means num 为256,512,1024,都出现错误,
通过gdb test core文件,追踪程序定位在main.cu 137行的memcpy,具体原因还不太清楚。
当means num为128时,程序运行正确。
通过思考一步一步终于把问题搞明白了,收益颇丰,所以写篇博客。
由于在memcpy处dump,所以出现的原因可能如下
1. 无效地址访问,如访问到系统保护的内存,访问的内存还没开辟,由于是写数据,还有可能是该地址是只读的,不过多数情况下是访问的内存还没有开辟。
2. 由于memcpy是非线程安全的,也有可能是多线程引起的。
但是程序中该处没有使用多线程,所以很可能是访问的内存还没有开辟,那么有两种可能
1. dest的内存分配不够大,导致往里面写数据写到没有开辟的内存处。
2. src的内存分配不够大。
由于该程序比较复杂,我写了一个小的程序来阐述。
代码如下:
运行程序,发现出现的错误和我们的程序一模一样,
那既然是源地址或者是目的地址内存分配的不够大,导致访问到无效地址,那么到底是源还是目的地址呢,我们如何判断呢?
很简单,如何开辟的地址足够大,即可以把PAGE *100个字节的数据复制进去,我们看能不能往里面写数据就可以知道啦。
方法如下:
重新运行程序,运行如下,发现在该语句出现错误,所以就证明是源地址开辟不够大,访问到无效地址。同样的方法测试dest是不是很容易。
也许你发现修改程序,当把程序复制的字节数变为1k字节数据,发现程序能够运行,这时候你会疑问,我们不是只开辟了100字节内存吗,应该也会出现错误才对啊?
但是如果你了解操作系统内存分配的原理的话,你就明白了,内存是按页分配的,虽然你只是malloc了100字节,但是操作系统给你分配的可不是只有100字节连续内存。
程序修改如下
程序正确运行:
当你把程序修改成超过一页内存大小,你发现怎么程序还能正常运行。
程序修改如下:
运行结果如下:
那可能是与具体的操作系统的内存分配机制有关,或者是你使用到的后面内存恰好已经分配了,这些都是可能的。
如果你还是不太明白,可以参考一下下面的关于malloc内存分配原理的知识:
1. http://blog.codinglabs.org/articles/a-malloc-tutorial.html
2. http://www.inf.udec.cl/~leo/Malloc_tutorial.pdf
- memcpy引起的core dump
- 一起 select 引起的崩溃------core dump
- sprintf函数错误引起的程序core dump
- memcpy造成的dump
- 调用系统函数引起的core dump问题------错误地调用了正确的系统函数
- 文件权限引起的core dump问题------那就chmod 777 config.txt吧
- [FFMPEG-BUG] sws_getContext()处理AV_PIX_FMT_NONE 帧格式引起的core dump
- core dump的意义
- core dump 的处理
- memcpy引起的一个bug
- 一次memcpy引起的bug
- pthread_mutex_lock引起的core
- System Dump和Core Dump的区别
- System Dump和Core Dump的区别
- System Dump和Core Dump的区别
- System Dump和Core Dump的区别
- 案例分享:如何通过JVM crash 的日志和core dump定位和分析Instrument引起的JVM crash
- select的fd超过1024将会非常危险------select导致core dump (句柄增多/句柄泄露引起)
- 几个机器学习算法及应用领域相关的中国大牛
- 纯CSS实现IOS开关效果
- 恩布企业IM iOS 0.9.5,免费企业即时通讯
- NSURLSession使用说明及后台工作流程分析
- Object C 多态
- memcpy引起的core dump
- Piranha 方案实现 WEB 负载均衡
- 让IE6 IE7 IE8 IE9 IE10 IE11支持Bootstrap的解决方法
- 黑马程序员——高新技术---反射--第25天--(最后一天)
- 前端上传组件Plupload使用指南
- PS快捷键大全
- ios “屏幕双缓冲”技术
- Android NDK开发(七)——现代化开发方式
- Object C 复制对象