调试访问冲突
我正在使用一个大型的闭源框架。我最近添加了一个新实体，现在在执行某些操作时遇到访问冲突。然而，它们发生在框架内的调用上，所以我不知道我实现了什么错误，因为我没有得到调用堆栈。
该违规行为在 CRT 文件 tidtable.c 中定义的函数 _CRTIMP PFLS_GETVALUE_FUNCTION __cdecl __set_flsgetvalue() 中报告。具体行为 PFLS_GETVALUE_FUNCTION flsGetValue = FLS_GETVALUE;。我不确定，但我认为这与函数指针有关？
错误消息为fmwk.exe 中 0x0000007a 处出现未处理的异常：0xC0000005：读取位置 0x0000007a 时发生访问冲突。。我的解释是，它试图访问对象中偏移量 0x7a 处的内容，但实际上给出了一个空指针。这是正确的吗？如果是，有没有办法找到该偏移量对应的内容？
下面是调用堆栈：
0000007a()
fmwk.dll!100f2630()
[Frames below may be incorrect and/or missing, no symbols loaded for fmwk.dll]
<lots of framework and windows dlls>
fmwk.exe!00402ef4()
msvcr100.dll!__set_flsgetvalue() Line 145 + 0xc bytes C
msvcr100.dll!_getptd_noexit() Line 498 + 0x7 bytes C
msvcr100.dll!_getptd() Line 523 + 0x5 bytes C
msvcr100.dll!_LocaleUpdate::_LocaleUpdate(localeinfo_struct * plocinfo=0x00000000) Line 243 + 0x5 bytes C++
msvcr100.dll!x_ismbbtype_l(localeinfo_struct * plocinfo=0x00000000, unsigned int tst=0, int cmask=1386664, int kmask=1414714) Line 219 C++
msvcr100.dll!_ismbblead(unsigned int tst=0) Line 172 + 0xe bytes C++
fmwk.exe!004010a0()
fmwk.exe!00404d61()
kernel32.dll!7c817077()
I'm using a large closed-source framework. I recently added a new entity, and now I'm getting access violations when performing some actions. However, they occur on calls from within the framework, so I don't know what I've implemented wrong, since I don't get a call stack.
The violation is reported in the function _CRTIMP PFLS_GETVALUE_FUNCTION __cdecl __set_flsgetvalue() defined in the CRT file tidtable.c. The specific row is PFLS_GETVALUE_FUNCTION flsGetValue = FLS_GETVALUE;. I'm not sure, but I think it is related to function pointers?
The error message is Unhandled exception at 0x0000007a in fmwk.exe: 0xC0000005: Access violation reading location 0x0000007a.. My interpretation is that it's attempting to access something at offset 0x7a into an object, but it's acually given a null pointer. Is this correct? If it is, is there a way of finding what that offset corresponds to?
Below is the call stack:
0000007a()
fmwk.dll!100f2630()
[Frames below may be incorrect and/or missing, no symbols loaded for fmwk.dll]
<lots of framework and windows dlls>
fmwk.exe!00402ef4()
msvcr100.dll!__set_flsgetvalue() Line 145 + 0xc bytes C
msvcr100.dll!_getptd_noexit() Line 498 + 0x7 bytes C
msvcr100.dll!_getptd() Line 523 + 0x5 bytes C
msvcr100.dll!_LocaleUpdate::_LocaleUpdate(localeinfo_struct * plocinfo=0x00000000) Line 243 + 0x5 bytes C++
msvcr100.dll!x_ismbbtype_l(localeinfo_struct * plocinfo=0x00000000, unsigned int tst=0, int cmask=1386664, int kmask=1414714) Line 219 C++
msvcr100.dll!_ismbblead(unsigned int tst=0) Line 172 + 0xe bytes C++
fmwk.exe!004010a0()
fmwk.exe!00404d61()
kernel32.dll!7c817077()
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用应用程序验证程序来调试此访问冲突。当坏事发生时，它应该更早停止执行，并且调用堆栈比这个更好。
看起来您在某处取消引用了 NULL 指针，但程序没有立即崩溃，因为它是未定义的行为，继续执行并稍后因奇怪的调用堆栈而崩溃。
Use Application Verifier to debug this access violation. It should stop execution earlier when bad thing happens with better call stack than this one.
Looks like you dereferenced NULL pointer somewhere but program did not crash immediately since it is Undefined Behaviour, continued executing and crashed a bit later with weird call stack.
关于你的问题：是的，访问 0x7A 可疑地看起来像取消引用偏移量 0x7a 处的 NULL 指针。 （也可能是像取消引用 0x20 和偏移量 0x5a 一样）。
如果没有源代码访问，就很难找出发生了什么。您可以尝试回溯您的代码，并找出您所做的哪些更改导致框架退出。然后，看看您使用的框架功能是否与应有的使用方式不同。如果这一切似乎没有尽头，您也可以向框架供应商报告错误，但我建议您在这样做之前确保错误不在您这边。
Regarding your question: Yes, accessing 0x7A suspiciously looks like dereferencing a NULL pointer at offset 0x7a. (Could also be something like dereferencing 0x20 with offset 0x5a though).
Without source code access it is hard to find out what's going on. You could try backtracking with your code and figure out which change you made that made the framework to bail out. Then, see if you are using a framework function different from how it is supposed to be used. If this all seems to lead to no end, you could also report a bug to your framework vendor, but I'd advise you to make sure the fault is not on your side before you do that.