什么可能导致此内存访问错误(C++)?可能是未定义的行为?

发布于 2024-11-25 07:42:32 字数 551 浏览 2 评论 0原文

我正在使用一个相对较大的类,到目前为止一切都运行良好(注意:我实际上没有编写该类,我只是添加了一些功能)。然而,在头文件中声明一个字符串后,现在一切都崩溃了(我收到内存访问错误)。如果我删除该字符串并重建,一切都会正常。

我实际上并没有对该字符串做任何事情......只是声明它的行为导致了一些奇怪的内存错误。

我无法比这更详细地解释,因为尝试解释每个函数是一种浪费。我应该在这里寻找什么样的东西来发现问题?是什么可能导致这种奇怪的行为?

错误本身是:
myFile.exe 中 0x65fd17fd (msvcp80d.dll) 处未处理的异常:0xC0000005:访问冲突写入位置 0xcdcdcdcd。

基本上,.h 文件中的所有更改都是:

StringType string1;

变成:

StringType string1;
StringType string2;

StringType是 basic_string 的扩展

I have a relatively large class that I'm working with and it's all worked fine so far (note: I didn't actually write the class, I'm just adding some functionality). However, after declaring one more string in the header file, everything now crashes (I get a memory access error). If I erase that string and rebuild, everything works fine.

I'm not actually doing ANYTHING with that string....just the act of declaring it is causing some weird memory error.

I can't explain in much more detail than this, since it would be a waste to try to explain every function. What kind of things should I look for here to find the problem? What might cause this weird behavior?

The error itself is:

Unhandled exception at 0x65fd17fd (msvcp80d.dll) in myFile.exe: 0xC0000005: Access violation writing location 0xcdcdcdcd.

Basically all that changed in the .h file was:

StringType string1;

Turned into:

StringType string1;
StringType string2;

StringType is an extension of basic_string

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

情未る 2024-12-02 07:42:32

您已在堆上分配了一些内存,但未能对其进行初始化。

0xcd 是调试堆使用的填充模式:在为程序提供动态分配的内存之前,它会使用该模式填充以帮助您查找未初始化的变量。

至于为什么更改类定义会影响结果,您可能会执行不正确的指针算术,访问超出动态分配对象末尾的内容,或者当您拥有更大的对象时不再表现为错误的任何其他内容之一目的。如果某些源是使用旧定义构建的,而某些源是使用新定义构建的,那么您也可能违反了单一定义规则。

有很多事情可能会导致此类问题:最好的办法是在发生这种情况时中断调试器,然后向后跟踪以查看错误的根源(有时这可能很有趣;我必须跟踪未初始化的变量通过网络连接一次)。

You've allocated some memory on the heap and failed to initialize it.

0xcd is a fill pattern used by the debug heap: before dynamically allocated memory is given to your program, it is filled with that pattern to help you find uninitialized variables.

As for why changing the class definition affects the outcome, you may be doing incorrect pointer arithmetic, accessing something beyond the end of a dynamically allocated object, or one of any number of other things that no longer manifests as a bug when you have a larger object. You could also be violating the one-definition rule if some of the source was built using the old definition and some of the source is built with the new definition.

There are many things that can cause this kind of problem: your best bet is to break in the debugger when it happens, and trace backwards to see where the error originated (sometimes this can be lots of fun; I had to trace an uninitialized variable across a network connection once).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文