c++ - system(mkdir) 在我的应用程序中挂起

Question

我们的代码库中有一个方法曾经可以正常工作，但现在不行了(没有对这个方法进行任何修改):

void XXX::setCSVFileName()
{
    //get current working directory
    char the_path[1024];
    getcwd(the_path, 1023);
    printf("current dir: %s \n",the_path);
    std::string currentPath(the_path);
    std::string currentPathTmp = currentPath + "/tmp_"+pathSetParam->pathSetTravelTimeTmpTableName;
    std::string cmd = "mkdir -p "+currentPathTmp;
    if (system(cmd.c_str()) == 0) // stops here
    {
        csvFileName = currentPathTmp+"/"+pathSetParam->pathSetTravelTimeTmpTableName + ".csv";
    }
//...
}

我尝试调试它，发现罪魁祸首是 if (system(cmd.c_str()) == 0) 。我在该行上放置了一个断点并试图越过它。它只是留在那里。调试器显示的 cmd 的值是:

Details:{static npos = , _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x306ae9e78 "mkdir -p /home/fm-simmobility/vahid/simmobility/dev/Basic/tmp_xuyan_pathset_exp_dy_traveltime_tmp"}}

我不知道系统在做什么，但我在 top 中的应用程序显示大约 100% 的 cpu 使用率。你遇到过这样的情况吗？

重要更新像往常一样，我开始将代码中的更改一个一个地恢复到问题发生之前的状态。令人惊讶的是，我发现了问题(但还没有找到解决方案......还没有)。

我在编译选项中添加了-pg 以启用gprof。这就是导致问题的原因。

也许你知道为什么 gropf 不在 system() 或 mkdir 行？？

谢谢

Answer 1

您在对其他问题的评论中说您需要使用 gprof 来支持您自己的分析器生成的结果。

换句话说，您想要编写一个分析器，并将其与 gprof 进行比较，并且您在质疑 -pg 标志是否正在使 system 挂起。< br/>我是说忘记 -pg 标志。所做的只是将 gprof 的调用计数代码放入编译器看到的函数中。

如果我是你，我会找到更好的东西来比较你的分析器。请记住，人们使用分析器的典型原因是寻找加速，他们可能认为收集测量值会帮助他们做到这一点。它没有。相反，它所做的是说服他们没有发现任何加速。(他们问这样的问题“new 占用了 5% 的时间，这是我的瓶颈，我怎样才能加快速度？”)这就是 gprof 为我们所做的。

这是一个分析器功能表，从差到好再到最好:

                              gprof   perf   zoom  pausing
samples program counter      |   X  |   X  |   X  |   X   |
show self % by function      |   X  |   X  |   X  |   X   |
show inclusive % by function |      |   X  |   X  |   X   |
samples stack                |      |   X  |   X  |   X   |
detects extra calls          |      |   X  |   X  |   X   |
show self % by line          |      |   X  |   X  |   X   |
show inclusive % by line     |      |   ?  |   X  |   X   |
handles recursion properly   |      |   ?  |   X  |   X   |
samples on wall-clock time   |      |      |   X  |   X   |
let you examine samples      |      |      |      |   X   |

这些很重要的原因是加速真的很擅长隐藏分析器:

• 如果未显示 % by line，加速可能在大型函数的任何位置。
• 如果未显示包容性百分比，则不会看到无关的调用。
• 如果样本不是在挂钟时间采集的，则不会出现无关的 I/O 或阻塞。
• 如果显示热路径，加速可以隐藏在它的任一侧。
• 如果显示调用图，加速可以隐藏在其中，方法是不局限于 A 调用 B，例如通过“隧道”函数。
• 如果显示火焰图，加速可以隐藏在其中，方法是不聚合可以删除的样本。

但他们无法逃避简单地检查堆栈样本。

---

附言以下是一些示例，说明加速比如何对分析器隐藏。
如果探查器显示“热路径”，它只显示堆栈样本的一小部分，因此它只能显示小问题。但是如果只比较堆栈样本的相似性而不是相等性，可能会出现一个明显的大问题:

加速也可以隐藏在调用图中，因为在这种情况下，A1 总是调用 C2 而 A2 总是调用 C1 的事实被“隧道函数”B(可能是多层)掩盖了。调用堆栈显示在右侧，人类很容易识别该模式:

在这种情况下，A 总是调用 C 的事实被 A 调用许多 Bi 函数中的任何一个(可能在多个层上)然后调用 C 所掩盖。同样，该模式在调用堆栈中很容易识别:

另一种方法是，如果堆栈样本显示大量时间花在调用具有相同名称但属于不同类(因此是不同的函数)或具有不同名称但具有相似目的的函数上。

在分析器中，这些共同将时间分成小部分，告诉您没有什么大事发生。这是人们“寻找慢功能”的结果，这实际上是一种盲目形式。