堆栈溢出和函数指针

Stackoverflow and function pointers

本文关键字:指针 函数 栈溢出 堆栈      更新时间:2023-10-16

我对这个问题很迷茫,我希望这里有人能提供帮助。

我的应用程序由数百个评估数字代码的函数组成(每个函数的源代码在 5MB 范围内),我使用函数指针std::map来管理函数。显然发生的事情是,当尝试将参数传递给其中一个函数时,我得到一个堆栈溢出,通过指向它的指针访问:

GDB 输出:

Program received signal SIGSEGV, Segmentation fault.
0x0000000001ec0df7 in xsectiond149 (sme=Cannot access memory at address 0x7fffff34b888
) at xsection149.c:2
2       Poly3 xsectiond149(std::tr1::unordered_map<int, Poly3> & sme, 
                           EvaluationNode::Ptr ti[], ProcessVars & s)

xsection149.c:2 只有用于函数定义的左大括号。

进程的/proc/<pid>/map仅显示最接近触发错误的地址的地址范围的地址范围:

7ffffff74000-7ffffffff000 rw-p 7ffffff73000 00:00 0                      [stack]

所以上述错误中的地址是越界的。

现在我的问题:我该如何解决这个问题?我无法绕开我可以在堆上分配什么......

在我的主要例程中发生的唯一想法是:

// A map containing O(10^4) Poly3 (struct with 6 doubles)
tr1::unordered_map<int, Poly3> smetemp;
// populates smetemp
computeSMEs(smetemp);
// Map of function pointers of type, O(10^3) elements
tr1::unordered_map<int, xsdptr> diagfunctions = get_diagram_map(); 

这怎么会溢出堆栈??

编辑:我试图在valgrind运行它,这是我得到的错误,谷歌没有提供任何有意义的信息:

valgrind: m_debuginfo/storage.c:417 (vgModuleLocal_addDiCfSI): 
    Assertion 'cfsi.len < 5000000' failed.
==491==    at 0x38029D5C: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)

编辑2:将函数反汇编到失败的程度(0x0000000001ec0df7)给我:

Dump of assembler code for function xsectiond149(std::tr1::unordered_map<int, Poly3,      std::tr1::hash<int>, std::equal_to<int>, std::allocator<std::pair<int const, Poly3> >,   false>&, std::vector<boost::shared_ptr<EvaluationNode>,    std::allocator<boost::shared_ptr<EvaluationNode> > >&, ProcessVars&):
<...+0>:      push   %rbp                                                               
<...+1>:      mov    %rsp,%rbp                                                          
<...+4>:      push   %r15                                                               
<...+6>:      push   %r14                                                               
<...+8>:      push   %r13                                                               
<...+10>:     push   %r12                                                               
<...+12>:     push   %rbx                                                               
<...+13>:     sub    $0xc96b58,%rsp                                                     
<...+20>:     mov    %rdi,%rbx                                                          
<...+23>:     mov    %rsi,-0xc8b078(%rbp)      // this instr fails                                         

函数的前几行为:

Poly3 xsectiond149(std::tr1::unordered_map<int, Poly3> & sme,   
                   std::vector<EvaluationNode::Ptr> & ti, 
                   ProcessVars & s)
{
    Poly3 sum(0,0,0,-2);
    Poly3 prefactor, expr;
    // CF*CA^2*NF*NA^(-2)
    double col0 = 0.5625000000000000000000000000;
    prefactor = col0*ti[0]->value()*s.Qtpow2*s.epow2*s.gpow6;
    expr =       (128*(s.p1p2*sme[192]*s.mt - s.p1p2*sme[193]*s.mt +
       1/2.*s.p1p2*sme[195]*s.mt - 1/2.*s.p1p2*sme[196]*s.mt -
       s.p1p2*sme[201]*s.mt + s.p1p2*sme[202]*s.mt +
       1/2.*s.p1p2*sme[210]*s.mt - 1/2.*s.p1p2*sme[211]*s.mt -
       1/4.*s.p1p2*sme[216]*s.mt + 1/4.*s.p1p2*sme[217]*s.mt -
       s.p1p2*sme[219]*s.mt + s.p1p2*sme[220]*s.mt -
       1/8.*s.p1p2*sme[1209]*s.mt + 1/8.*s.p1p2*sme[1210]*s.mt +
       1/2.*s.p1p2*sme[1215]*s.mt - 1/2.*s.p1p2*sme[1216]*s.mt +
   // .....
}

(请注意,我在实验过程中更改了函数的签名)

谁能维持生计?您需要哪些其他信息?对不起,但我几乎没有 asm 的经验。

编辑3:使用ulimit -s <size>增加堆栈大小就可以解决问题。谢谢大家的帮助!

看起来函数xsectiond149需要一个大约 13 MB 的堆栈帧(请注意指令sub $0xc96b58,%rsp,并且一旦它尝试在两个指令后在那里写下一些东西就会失败)。在调用函数之前,您需要确保线程具有足够大的堆栈(默认情况下不会)。

您还可以考虑更改代码生成器,以便在堆而不是堆栈上分配更多内容。

获取 Valgrind 并在构建后在 Valgrind 下运行您的程序(使用 memcheck,默认工具)。这样,您将更容易找到故障源。

您还可以在进入调试器(通常是 GDB)的模式下运行 Valgrind,然后您可以使用所有很酷的 GDB 命令来检查调用方堆栈帧的值等等。

无论哪种方式,如果你遇到困难,瓦尔格林德应该帮助你找到一些继续的指示。

至于你的编辑,这是我的回复(引用自Valgrind源代码,storage.c的r11604):

445     /* sanity */
446     vg_assert(cfsi.len > 0);
447     /* If this fails, the implication is you have a single procedure
448     with more than 5 million bytes of code. Which is pretty
449     unlikely. Either that, or the debuginfo reader is somehow
450     broken. 5 million is of course arbitrary; but it's big enough
451     to be bigger than the size of any plausible piece of code that
452     would fall within a single procedure. */
453     vg_assert(cfsi.len < 5000000);