程序在另一台机器上运行崩溃,虽然找到的避免该错误的方法,但稀里糊涂的,不知道为什么?

yeyuboy 2005-04-13 01:57:58
出错描述: 程序在我的开发用机器上运算无误,但放到用户机器上崩溃了,跟踪后发现,同样的程序在两台机器上有一句代码的执行不一样:

/***************************************************************************************/
//源代码,CarIORec类的构造函数:
CarIORec::CarIORec(_ConnectionPtr connPtr/* =0 */, long nRecId/* =-1 */, CString strCarCode/* =_T */, COleDateTime dtIO/*=COleDateTime::GetCurrentTime()*/, bool bRecType/*=true*/)
:m_connPtr(connPtr), m_nRecId(nRecId), m_strCarCode(strCarCode), m_dtIO(dtIO), m_bRecType(bRecType)
{
}
//增加记录按钮按下时的处理函数:
void CCarIOView::OnButtonAdd()
{
CarIORec ioRec(GetDocument()->m_adoconn.GetConnection()); //创建CarIORec类对象导致程序崩溃
.....
}
//跟踪比较汇编代码:==================================
129: void CCarIOView::OnButtonAdd()
130: {
131: CarIORec ioRec(GetDocument()->m_adoconn.GetConnection());
0041604E push 1
00416050 lea eax,[ebp-40h]
00416053 push eax
00416054 call COleDateTime::GetTickCount (0042723a) //未重编译时
//在用户机器上跟踪调试时导致错误的调用,GetTickCount JMP到
// CDateTimeCtrl::GetTime(COleDateTime& timeDest)
//而在我开发用的机器上,GetTickCount JMP到COleDateTime::GetCurrentTime
//于是在用户机器上进行重新编译,有些改变:
00416054 call COleDateTime::GetTickCount (0042715a) //重编译后
//现在和我开发用机器上的一样是JMP到COleDateTime::GetCurrentTime,程序正确了
........
}

//////////////////////////////////////////////////////////////////////////////////////////
//在用户机器上出错时的细节:
//在用户机器上JMP到GetTime后的执行细节:
BOOL CDateTimeCtrl::GetTime(COleDateTime& timeDest) const
{
SYSTEMTIME sysTime;
BOOL bRetVal = TRUE;

LRESULT result = ::SendMessage(m_hWnd, DTM_GETSYSTEMTIME, 0, (LPARAM) &sysTime);
if (result == GDT_VALID)
{
timeDest = COleDateTime(sysTime);
bRetVal = TRUE;
ASSERT(timeDest.GetStatus() == COleDateTime::valid); //这里断言失败!
}
else if (result == GDT_NONE)
{
timeDest.SetStatus(COleDateTime::null);
bRetVal = TRUE;
}
else
timeDest.SetStatus(COleDateTime::invalid);
return bRetVal;
}

//CDateTimeCtrl::GetTime执行后立即执行以下程序:
_AFXDISP_INLINE COleDateTime::COleDateTime(const COleDateTime& dateSrc)
{ m_dt = dateSrc.m_dt; m_status = dateSrc.m_status; } //程序崩溃:deteSrc无效
/***************************************************************************************/
解决方法:
于是我将工程设置(如:运行库\调试信息\RTTI等进行排查,发现当用了DEBUG版本的多线程运行库程序在
用户机器上运行就会崩溃,而换成非DEBUG版本的多线程运行库后程序运行无误.

我的困惑:
在开发机器上,程序在用了DEBUG版本的多线程运行库,程序总是运算正确,而在拷贝到客户机器上后,即使客户机器上装了VC还是会运行不了(只要一用到COleDateTime就出错),如果在客户机上重新编译程序,
程序就正确了.为什么???????????
...全文
151 1 打赏 收藏 转发到动态 举报
写回复
用AI写文章
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
a123a123 2005-04-13
  • 打赏
  • 举报
回复
高 薪 诚 聘 V C + + 精 英

软 媒 ( 深 圳 ) 成 立 于 二 零 零 二 年 五 月 。由 新 加 坡 私人 投 资 基 金 注 资 。

软 媒 的 业 务 ,专 注 于 软 件 的“现 场 开 发 工 具”,持 续 的 挖 掘 用 户 使 用 软 件 的 核 心 利 益 。

软 媒 堪 称 深 圳 第 一 大 软 件 军 团,集 结 了 一 大 批 专 兼 职V C + + 软 件 业 界 精 英 。

软 媒 对 于 核 心 技 术 人 员 ,采 取 “ 四 高 ” 的 管 理 政 策 。

( 一 ) 高 薪
“ 永 远 让 薪 水 跑 在 能 力 前 面 ” 是 软 媒 的 座 右 铭 。

( 二 ) 高 技 术
软 媒 公 司 内 部 针 工 具 型 软 件 研 发 ,形 成 自 主 产 权 的 系列 软 件 架 构 。

( 三 ) 高 手 军 团
软 媒 的 每 个 高 级 工 程 师 , 都 是 身 手 不 凡 的 业 界 精 英 , 形 成 了 浓 厚 的 高 科 技 氛 围 。

( 四 ) 高 素 质 用 户 群
“ 一 个 软 件 离 开 了 它 的 用 户 就 是 垃 圾” 并 不 过 分 ,软 媒 提 供 了 7 * 2 4 小 时 的 在 线 用 户 群 引 导 软 件 的 需 求 。


产 品 介 绍

< 系 列 软 件 研 发 工 具 >
让 九 亿 农 民 兄 弟 都 能 开 发 出 自 己 喜 爱 的 软 件 。

提 示 : 凡 符 合 本 职 位 要 求 者 , 可 以 直 接 来 面 试 无 须 投 放 简 历 。

要 求 : 精 通 标 准 C \ C + + 结 构 化 程 序 设 计 。
1 、 要 求 有 V C + + 软 件 开 发 经 验 。
2 、 精 通 W i n d o w s 界 面 开 发 , 熟 练 使 用 C D C 绘 图 类 。
3 、 具 有 良 好 的 独 立 开 发 能 力 和 自 主 开 发 能 力 。
4 、 有 工 具 型 软 件 开 发 经 验 者 优 先 。

工 作 职 责 :
1 、 开 发 工 具 软 件 及 其 构 件 。
2 、 独 立 自 主 设 计 工 具 使 用 流 程 。
3 、 一 切 设 计 都 基 于 用 户 需 求 。
4 、 不 需 要 团 队 开 发 经 验 。
5 、 要 求 有 良 好 的 用 户 需 求 实 现 能 力 。

基 本 工 资 :
1 、 高 级 软 件 工 程 师 : 9 , 0 0 0 元 / 月

联 系 方 式 : R i c h m a i n @ d u o s o f t . c n

http://www.jobsdb.com.cn/main/jobseeker/JobTemplates/Default/CN/JobDetail.asp?CompanyID=109434&JobPostID=3178881&FromFlag=&Language=CN&Page=1 & T e m p l a t e I D = D e f a u l t

16,472

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧