libc ++是否保持内部状态?

wil*_*ick 1 c++ stl libc++

libc ++是否维护一个进程范围内部状态,其中代码的一部分中发生的操作可以通过调用std ::*类(例如std :: set)来影响代码的某些远程部分?为了更具体一点,我见过这样的崩溃(仅显示堆栈跟踪的顶部):

std::__1::__tree<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::__insert_unique(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 156, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)

解决方法是升级不直接参与崩溃的库,以纠正C++ ABI问题.我很惊讶ABI问题可能会对原因造成影响,并且想知道标准库本身是否有某些状态已损坏?

650*_*502 5

C++不提供受保护的环境.如果代码的任何部分做了一些禁止的事情(例如,删除一个对象两次,写下数组的限制......)那么代码的任何其他位置都可以立即执行,也可以在很长时间之后执行任何操作.

实际上,问题通常是错误只是显然没有造成任何伤害,因为程序(显然)只是起作用.

关于违反ABI的错误是非常低的级别(例如,可能需要机器代码来保留某个寄存器而它没有)并且没有什么可以让您感到惊讶.欢迎来到"未定义的行为"地狱.

在特定的std::setstd::map某些实现中,已知依赖于标记,因此覆盖全局变量可以影响甚至稍后创建的映射和集合.

此外,C++中的几乎所有内容都依赖于动态分配的内存,违反ABI的程序可能会破坏与之相关的数据结构,并且这些效果可能会在以后显示数百万条执行的指令(例如,当损坏的空闲块被重新分配给其他内容时).