C++删除具有有效地址的指针
我正在使用 Poco C++ 库并导致奇怪的问题。 Poco 使用自己的共享指针类 SharedPtr 进行内部指针操作。在我的例子中，静态对象 Poco::SSLManager 具有证书处理程序对象的 SharedPtr 成员。当程序运行结束时，静态对象被删除，我捕获分段错误。 使用 GDB 调试器我看到核心转储但不明白问题。删除SharedPtr对象时发生段错误（简单操作：delete pObj），但对象具有有效地址，例如-0x8fcbed8。
为什么删除有效地址的指针会导致分段错误？
这可能是因为对象在应用程序的 fork 副本中创建并在 main 中销毁？
I am using Poco C++ library and cause strange problem.
Poco using own shared pointer class SharedPtr for internal pointer operations. At my case static object Poco::SSLManager has SharedPtr members of certificate Handlers objects. When program run ends, static object is deleted and I catch segmentation fault.
Uses GDB debugger i see core dump and don't understand problem. Seg fault is occurred when deleting SharedPtr object (simple operation: delete pObj), but object has valid address, such as - 0x8fcbed8.
Why delete pointer with valid address can cause segmentation fault?
It's may be because object create in fork copy of application and destroy in main?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
有效地址只是一个可访问的地址。这并不意味着它适合删除。您只能
删除从new返回的内容。如果您没有新建它，则无法删除它。删除静态或自动对象是未定义的行为 - 以及您可能从new之外的任何其他来源获得的行为。A valid address is just an accessible address. That doesn't mean that it's right for delete. You can only
deletewhat you got back fromnew. If you didn'tnewit, you can'tdeleteit. Deleting a static or automatic object is undefined behaviour- as well as one you might obtain from any other source apart fromnew.您谈到使用
共享指针。如果该删除是 pObj 上的最后一次删除，则可能是该对象最后一次被删除......因此共享指针指向的对象最终将被销毁。在这种情况下，pObj 的析构函数被调用，也许您会从那里得到段错误。另一方面，根据 Poco 库使用的共享指针的实现，您可能通过调用删除来滥用共享指针。
You speak about using a
shared pointer. If that delete is the last delete on the pObj, it might be that it's the last time that the object is being deleted.. and so the object that the shared pointer points to will finally be destroyed. In that case thedestructorof pObj is called and maybe you get the Seg Fault from there.On the other hand depending on which implementation of shared pointer the Poco lib uses, it might be that you are misusing the shared pointer by calling delete on it.
正如另一个人所说，并不是因为你的指针看起来像 0x8fcbed8 一样“好”，所以它是一个正确的指针。
事实上，如果您使用“删除”，指针将保留其值。但您不应该再使用它。 （在删除之后将其设置为 NULL 是一个很好的做法，这样它在调试器中显示为“空”。）
如果您使用 Linux 进行开发，有一个工具可以帮助您找到问题所在。它是 valgrind ：（
只需在您通常启动的命令前面添加“valgrind”。如果尚未安装 valgrind，则必须在您的发行版上有一个包，因为它是一种广泛使用的工具。）
然后 valgrind 会在程序运行时检查您的程序（稍微减慢速度），并在您删除不应该删除的内容时立即报告您。 （以及很多其他错误）
as the other have said, it's not because your pointer looks "good" like 0x8fcbed8 that it's a correct pointer.
In fact, if you use "delete", the pointer will keeps its value. But you should not use it any more. (It's a good practice to set it to NULL just after a delete so it appears "empty" with a debugger.)
There is a tool that could help you to find what is wrong if you are developping with linux. It's valgrind :
(just add "valgrind" in front of the command you usually launch. Install valgrind if not already here, must have a packet for it on your distro since it is a widely used tool.)
Then valgrind will inspect your program while it run (slowing it a bit) and report you immediatly as soon as you delete something you should not. (and a lot of other errors)
这是一个非常困难的问题，我不完全理解问题，但我尝试解释它和我的解决方案。
问题是特定于平台的，并且仅发生在带有 gcc 4.5.5 编译器和 Poco 库的 Gentoo linux 上。
我有一个使用模块（插件）来处理不同请求的守护进程。模块和守护进程使用一个使用 poco 库的静态库。在静态库中有创建 SSL 连接的代码，并因此创建 SSL 管理器。静态库链接到模块和守护程序。
在工作守护进程结束后，我遇到了问题中描述的分段错误。我将静态库更改为共享库，问题消失了，没有段错误。一切正常。
真的，我不明白，但似乎是 gentoo 上的 gcc 编译器错误。在其他 Linux 上，其他 gcc 都可以很好地使用静态库。
It's very difficult problem and i don't understand problem full, but i try to explain it and my resolution.
Problem is platform-specific and occurres only on Gentoo linux with gcc 4.5.5 compiler with Poco Libraries.
I have daemon that use modules (plugins) for processing different requests. Modules and daemon use one static library that use poco library. In static library have code to create SSL connections and as result creates SSL manager. Static library is linked to module and to deamon.
And after end's of working deamon i have segmentation fault that describes in my question. I change static library to shared library and problem is gone, no seg faults. All works fine.
Really, i don't understant it, but seems it's gcc compiler bug on gentoo. On others linux with other gcc all works good with static library.