容器问题：*** 检测到 glibc *** free()：无效指针：0x41e0ce94 ***
我在 Linux 上有一个 C++ 程序，该程序在一段时间后崩溃，并显示以下消息：
*** glibc detected *** free(): invalid pointer: 0x41e0ce94 ***
在程序内部，我广泛使用了容器。 他们必须存储简单类的对象。
编辑 2009-4-17：
与此同时，很明显该错误与简单类无关。 如果我更改容器以保存其他数据类型，该错误仍然会发生。 问题一定出在我的代码中的其他地方，我现在正在尝试解决它......
I have a C++ program on Linux that crashes after some time with the message:
*** glibc detected *** free(): invalid pointer: 0x41e0ce94 ***
Inside the program I make extensive use of containers. They have to store objects of a simple class.
EDIT 2009-4-17:
In the meantime it seems clear that the error has nothing to do with the simple class. The error still occurs if I change the containers to hold other datatypes. The problem must be somewhere else in my code, I'm trying to figure it out at the moment...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你的析构函数里面有什么？ 可能它没有 cstring。 如果是这种情况，那么您在实例上共享 cstring 指针，然后每个实例都会释放相同的指针。
What is inside your destructor? Probably it does free of the cstring. And If it is the case then you share your cstring pointer over instances and each instance then frees the same pointer.
考虑使用 std::string 来保存字符串值而不是原始字符指针。 这样您就不必担心在赋值、复制和销毁方法中管理字符串数据。 您的问题很可能就在那里。
编辑：您发布的新类没有问题，如果您仅使用 char * 指向字符串常量，第一个版本也没有问题。 问题出在程序的其他地方，或者出在你使用类的方式上。 您将不得不花费更多时间深入调试器和/或 valgrind 来追踪问题。 我会找出指定地址指向的内容，并尝试确定为什么它被释放两次。
Consider using a std::string to hold the string value instead of a raw char pointer. Then you won't have to worry about managing the string data in your assignment, copy, and destruction methods. Most likely your problem lies there.
Edit: There's no issue with the newer class you posted, and no problem with the first version if you're only using the char * to point to string constants. The problem lies elsewhere in the program or with the way you're using the class. You'll have to spend more time digging in the debugger and/or valgrind to track down the problem. I would figure out what is pointed to at the specified address and try determine why it's being freed twice.
据猜测，您的复制构造函数、赋值操作或析构函数中有问题 - 您需要显示这些代码。
编辑：刚刚注意到你没有赋值运算符 - 假设你的复制构造函数 & 析构函数没问题，你还需要一个赋值运算符，如 std:; 容器会使用它。
At a guess, there is something wrong in your copy ctor, assignment op or destructor - you need to show the code for those.
Edit: Just noticed you don't have an assignment operator - assuming your copy constructor & destructor are OK, you need an assignment operator too, as the std:; containers will use it.
我一直在与我们正在开发的 C/C++ 应用程序作斗争，我想到的第一个想法是
您已释放该对象，但指针仍保持方向。
像 Valgrind 这样的工具可以帮助您检测代码中可能存在的错误。 安装：
sudo apt-get install valgrind
并使用它：
valgrind --tool=memcheck --leak-check=full ...
它会在程序运行时报告错误，并且在程序结束后也会给您一个报告。 唯一的问题是 valgrind 识别为可能的问题可能不是真正的问题。 但这是一个起点。
I have been fighting with a C/C++ application we are developing, and the first ideas that come to my mind are
You have freed the object, but the pointer still holds the direction.
A tool like Valgrind may help you to detect possible errors in the code. To install:
sudo apt-get install valgrind
And to use it:
valgrind --tool=memcheck --leak-check=full ...
It will report errors while the program is running, and it will give you also a report after the program ends. The only problem is what valgrind identifies as a possible problem may not be a real problem. But it is an starting point.
这肯定是一个错误的字符串值。 如果是悬空指针问题，使用 std::string 在这方面可能会有所帮助。 还要确保所有字符串初始化按预期工作。
如果我正确理解该类，您会假设 m_cstring 中驻留的任何内存都不会在该类的生命周期内被释放。 在您的情况下，这也意味着容器的使用寿命。 检查你的范围。
您可能遇到的另一个问题是，如果您的析构函数正在删除 cstring，那么在构造函数中使用默认值是一个非常糟糕的主意，因为您将尝试释放静态分配的 cstring。
在 C++ 中，可以定义一个应该返回字符串的函数，但不会返回任何内容，最终会得到一个错误的字符串（通常编译器会捕获“达到非 void 函数的结尾”，但不会总是）。
使用 valgrind 也是如此。
作为阅读各种评论后的附录，程序中其他地方的内存错误总是有可能损坏其中一个字符串。
编辑 4-16
此时，我将验证对象的值在构造/析构时是否格式良好。 （尝试打印它们？）如果一切看起来都不错，您可能需要在代码的其他位置查找错误。
It's most certainly a bad string value. Using std::string maybe help in this regard if it is a dangling pointer issue. Also ensure all the string initializations work as expected.
If I understand the class correctly, you assume that whatever memory resides at m_cstring won't be deallocated for the lifetime of the class. Which in your case also means for the lifetime of the containers. Check your scopes.
Another problem you may be encountering is if your Destructor is deleting the cstring then using a default value in the constructor is a really bad idea as you will be trying to deallocate a statically allocated cstring.
It is possible in C++ to define a function that is supposed to return a string, but doesn't return anything and you wind up with a bad string (Typically the compiler will catch the 'Reached end of non-void function', but not always).
Ditto on using valgrind.
As an addendum after reading various comments, there's always the possibility that a memory error somewhere else in the program corrupted one of the strings.
EDIT 4-16
At this point I would verify the values of the object are well formed on construct/destruct. (try printing them?) If everything looks good, you may have to look elsewhere in your code for the error.