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

我们的代码库中有一个方法可以正常工作，但现在不能再工作了(对此方法不做任何修改):

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的值为:

我不知道系统在做什么，但是我在top中的应用程序显示了大约100％的CPU使用率。
您遇到过这种情况吗？

重要更新
像往常一样，我开始将代码中的更改逐一还原到问题之前的状态。出乎意料的是，我发现了问题(但没有找到解决方案……。)。

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

可能您对gropf为什么不将system()或mkdir排成一行有一些了解？

谢谢

最佳答案

您在对另一个问题的评论中说，您需要使用gprof来支持自己的探查器生成的结果。

换句话说，您想编写一个探查器，并将其与gprof进行比较，并且您正在质疑-pg标志是否使system挂起。
我是说忘了-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，则加速可能在大型函数中的任何位置。

如果未显示包含％的内容，则不会看到无关的 call 。

如果未在墙上时钟时间采样，则看不到无关的I / O或阻塞。

如果显示了hot-path，则加速可以隐藏在其任一侧。

如果显示了调用图，则可以通过不定位到A调用B(例如通过“隧道”功能)将加速隐藏在其中。

如果显示了flame-graph，则可以通过不汇总可以删除的样本来隐藏加速器。

但是他们不能仅仅检查堆栈样本就隐藏起来。

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

加速也可能隐藏在调用图中，因为在这种情况下，“隧道函数” B(可能是多层)掩盖了A1始终调用C2和A2始终调用C1的事实。
调用堆栈显示在右侧，并且人员可以轻松识别该模式:

在这种情况下，A始终调用C的事实被A调用多个Bi函数中的任何一个(可能跨多个层)然后调用C的事实所掩盖。
同样，该模式可以在调用堆栈中轻松识别:

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

在探查器中，这些合谋将时间分成少量，告诉您没有什么大不了的。
这是人们“寻找缓慢的功能”的结果，实际上是盲目的一种形式。

关于c++ - system(mkdir)卡在我的应用程序中，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/25660216/