STLport崩溃（比赛条件，只有达尔文？）

当我在达尔文运行STLport时，我得到一个奇怪的崩溃。（没见过比它在Mac上其他地方，但完全相同的东西碰撞双方的i686和PowerPC）。这就是它看起来像在gdb：STLport崩溃（比赛条件，只有达尔文？）

Program received signal EXC_BAD_ACCESS, Could not access memory. 
Reason: 13 at address: 0x0000000000000000 
[Switching to process 21097] 
0x000000010120f47c in stlp_std::__node_alloc_impl::_M_allocate()

它可能在STLport中的一些设置，我注意到Mac.h和MacOSX.h在功能上似乎远远落后。我也知道它一定是某种竞争条件，因为它不会仅仅通过调用这个方法（隐含调用）而发生。崩溃主要发生在我推送系统时，运行10个同时执行大量字符串处理的线程。

我想到的其他理论与编译器标志（configure脚本）和g ++ 4.2错误（似乎4.4.3不在Mac上，ObjectiveC支持，我需要链接）有关。

HELP !!! :)

编辑：我运行单元测试，它做各种事情。当我启动推送系统的10个线程时会出现此问题;它总是归结为std :: string :: append，最终归结为_M_allocate。由于我甚至无法得到导致问题的代码的下降转储，所以我认为我做的不好。它是否会如此，因为它试图在指令指针0x000 ... 000处执行？ dynlibs是否在Windows中使用跳转表构建为DLL？可能是因为某种原因，这样的跳转表被覆盖了吗？这可能会解释这种行为。（代码是巨大的，如果我用完其他想法，我会在这里发布一个最小崩溃示例。）

来源

2010-03-05 Jonas Byström

你不能“运行”STLport - 它是一个库 - 你写的是什么C++代码导致崩溃？ – 2010-03-05 14:36:05

Neil说了什么，还有，值得一看的是代码是如何线程安全的。 – 2010-03-05 14:37:38

此问题是由unrelated crash bug引起的，导致内存覆盖导致STLport崩溃。

来源

2010-03-29 08:21:56

hmm .. STLPort使用分配器，它需要平台内存并在需要时将其内部池化到数据结构中。

只要检查崩溃发生的时间，给予正在执行的线程的堆就足以让一个alloc发生。即使分配失败，也可能发生这种崩溃。

我不确定您正在使用的当前配置中的STL分配器的粒度。检查stl_config.h。

来源

2010-03-09 07:44:37 vprajan

我一直在研究这个代码，但还没有真正理解可能出错的地方。所以你是说每个线程都被赋予了堆的单独部分，即使空间不足，它也不会被重新分配。听起来*非常*容易出错。我会进一步研究这一点。 – 2010-03-09 13:44:10

STLport崩溃（比赛条件，只有达尔文？）

回答

相关问题