为什么new / malloc在Win x64上失败虽然有大量的可用内存？ [英] Why does new / malloc fail on Win x64 although there is plenty of free RAM?

问题描述

我有一个强大的递归函数，使用 new 为每个函数实例创建一个非常小的 std :: multimap c $ c>（它在std lib中递归到 malloc / calloc ）。经过几百个递归新失败，虽然我在Windows XP x64上使用本机64位应用程序。本机有10 GB RAM，应用程序只使用大约1GB。没有其他大型应用程式正在执行。

这是在启动程式并启动递归功能后的几分钟。递归函数在这一点上被调用了大约150.000次，可能有最大值。递归了几百个。发生的问题不是堆栈溢出。

我使用Visual Studio 2005和dinkumware STL。

编辑：
好​​的，这里是一些代码。
我现在重新安排代码，并将地图放在堆栈，但它使用新的初始化 - 它失败。我也试过一个std :: multimap而不是hash_multimap。

  int TraceBackSource（CalcParams * CalcData，CKnoObj * theKno，int qualNo，
双maschFak，double partAmount，int MaschLevel，char * MaschID，
 double * totalStrFlow，int passNo，
 CTraceBackData * ResultData）
 
 {typedef std :: hash_multimap& CStrObj * StrFMap; 
 StrFMap thePipes; 
 
 for（...）
 {
 ... 
 thePipes.insert（std :: make_pair（thisFlow，theStr））; 
} 
 
 //最大。 thePipes中有5个元素
 for（StrFMap :: iterator it = thePipes.begin（）; it！= thePipes.end（）; it ++）
 {
 ... 
 try 
 {
 TraceBackSource（CalcData，otherKno，qualNo，maschFak * nodeFak，nodeAmount，SubMaschlevel，newMaschID，totalStrFlow，passNo，ResultData）; 
} 
 catch（std :: exception& it）
 {
 Trace（0，*** Exception，％s，it.what（））; 
 return 0; 
} 
 
 return 0;有趣的是，第一个失败运行到catch处理程序中，并且在第一次失败时， 
解决方案
你的数字表明一个容易默认的1MB堆栈大小（c150K×8）。所以从快速查看你的代码（和map :: insert特别是，而不是提供'...'代码）你正在与stackoverflow.com交互：）
 
 
 
你可能会碰到它运行它的操作系统。在Windows上使用VS链接器设置或使用editbin.exe或一些异乎寻常的unportable api，三倍你的堆栈大小，看看它是否显着改变观察到的递归计数在异常时。
 
I have a strongly recursive function, that creates a (very small) std::multimap locally for each function instance using new (which recurses to malloc/calloc in the std lib). After some hundred recursions new fails although i am using a native 64Bit application on Windows XP x64. The machine has 10 GB RAM, The application only uses about 1GB. No other big apps are running.

This happens a few minutes after starting the program and starting the recursive function. The recursive function has been called about 150.000 times at this point with a probably max. recursion of some hundreds. The problem occurring is not a stack overflow.

I am using Visual Studio 2005 and the dinkumware STL. The fault occurs in a release build.

EDIT: 
Ok, here is some code.
I rearranged the code now and put the map on the stack, but it uses new to initialize - there it fails. I also tried with a std::multimap instead of hash_multimap. All of this die not change the behavior.
    int TraceBackSource(CalcParams *CalcData, CKnoObj *theKno, int qualNo, 
                            double maschFak, double partAmount, int MaschLevel, char *MaschID, 
                            double *totalStrFlow, int passNo, 
                            CTraceBackData *ResultData)

{   typedef std::hash_multimap<double, CStrObj *>StrFMap;
    StrFMap thePipes;

        for(...)
        {  
            ...
            thePipes.insert(std::make_pair(thisFlow, theStr));
        }

        // max. 5 elements in "thePipes"
        for(StrFMap::iterator it = thePipes.begin(); it != thePipes.end(); it++)
        {
            ...
            try
            {
                TraceBackSource(CalcData, otherKno, qualNo, maschFak * nodeFak, nodeAmount, SubMaschlevel, newMaschID, totalStrFlow, passNo, ResultData);
            }
            catch(std::exception &it)
            {   
                    Trace(0, "*** Exception, %s", it.what()); 
                    return 0;
            }

            return 0;
        }
}
Interestingly, the first failure runs into the catch handler, quite a bit later on i end with a ACCESS VIOLATION and a corrupted stack.
解决方案
Your number suggests an easily defaulted 1MB stacks size (c150K x 8 ). So from a quick look at your code (and that map::insert especially and not providing the for'...' code  ) you are running into an interaction with  stackoverflow.com :)

You are probably hitting it for the OS you're running it on. On Windows use the VS linker setttings or use editbin.exe or some exotic unportable api, triple your stack size and see whether it significantly changes the observed recursive count at time of exception.

                        
这篇关于为什么new / malloc在Win x64上失败虽然有大量的可用内存？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！