现象:
最近发现文件服务客户端的 sdk 异常,上传文件,文件数据经常只传一部分就进入完成状态。客户端 SDK 是 windows 的,打开 vs 跟踪文件已上传数据量,单步调试,确实发现已上传数据量在某个地方被赋值成文件的大小了。
很奇怪,我在该变量所有被赋值的地方都下了断点,都没有发现断点触发修改,到底哪里将这个变量的数据修改了呢?用 VS 的“数据断点”功能,竟然发现在另外一个地方(UpdateTaskProgress)触发了断点,该对象被强制转换成同级的其它派生对象。
classCDownloadTask:publicCTask {
public:
CDownloadTask() : m_ullDownloadedSize(0) {}
virtual~CDownloadTask() {}
public:
unsigned__int64 m_ullDownloadedSize;//已下载文件大小
};
classCUploadTask:publicCTask {
public:
CUploadTask() : m_bPicResample(false), m_ullUploadedSize(0) {}
virtual~CUploadTask() {}
public:
bool m_bPicResample;//是否有压缩图片
std::stringm_strFileType;//文件类型
unsigned__int64 m_ullUploadedSize;//已上传文件大小
};
boolCTaskMgr::UpdateTaskProgress(intiTaskID,unsigned__int64 ullFileSize,unsigned__int64 ullNowSize) {
CTask* pTask =NULL;
if(m_mapTask.Lookup(iTaskID, pTask) && pTask !=NULL) {
CDownloadTask* pDLoadTask = (CDownloadTask*)pTask;
pDLoadTask->m_oFileInfo.m_ullFilesize = ullFileSize;
pDLoadTask->m_ullDownloadedSize = ullNowSize;
return true;
}
return false;
}
文件上传下载任务,继承了 CTask。通过以上代码,在调试上传的时候,会触发 UpdateTaskProgress 接口。但是该接口,应该是上传CUploadTask 的类,而不是下载CDownloadTask,这里结构强制转换错误了。所以导致了,数据会出现意想不到的结果。庆幸这问题,出现在调试期间,如果是生产环境,或者大并发的服务系统,要找出这个隐含的 bug 确实只能靠缘分了。
解决方案:
CDownloadTask* pDLoadTask = (CDownloadTask*)pTask;
像这种直接强制转换是不安全的,继承于相同基类的派生类如果在运行中的数据结构类型不匹配,系统并不会通知用户报错。难于定位问题。应该用dynamic_cast (它会在运行期对可疑的转型操作进行安全检查)。类型不匹配会返回 NULL;
CDownloadTask* pDLoadTask =dynamic_cast(pTask);
调试手段总结:
如果不清楚变量是在哪里发生改变的,VS 系列,可以用“数据断点”功能,监控某个变量的改变。类似于 gdb 的 watch 功能。
数据断点更精彩内容,请关注我的博客:https://wenfh2020.com
网友评论