3

かなり自明です。「新しいベクター」行でSIGABRTを引き起こしているメソッドは次のとおりです。

vector<string> * Task::arguments() {
    vector<string> *args = new vector<string>(); // CAUSES SIGABRT
    int count = sizeof(_arguments);
    for (int x = 0; x < count; x++) {
        string argument(_arguments[x]);
        args->push_back(argument);
    }
    return args;
}

他の場所では、問題なく正確な行を呼び出していることに注意してください。Task クラスのインクルードのリストは次のとおりです。

#include <vector>
#include <unistd.h>
#include <string>
using namespace std;
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>

何かご意見は？

4

4 に答える 4

6

このコードには実際のエラーはありませんが、このスタイルは、優れた C++ の本が緊急に必要であることを示唆しています。

@James が質問に対するコメントで述べたように、動的に割り当てられたベクター オブジェクトを使用することはほぼ確実に間違っており、それをスマート ポインターに保持しないことは確かに間違っています。
コードの他の場所でもこれを行った場合は、ヒープを台無しにしている可能性がnew非常に高く、これはいつクラッシュするかを考えることができる唯一のケースです。

于 2011-02-16T17:38:11.717 に答える
3

int count = sizeof(_arguments);かなり疑わしいようです。

sizeof配列の要素数ではなく、サイズをバイト単位で提供します（各要素が正確に1バイトの場合を除くchar）。

乾杯 & hth.,

于 2011-02-20T23:12:01.930 に答える
3

問題はベクトルの割り当てではなく、for() ループ内にあることがわかりました。適切な do/while ループに置き換えると修正されました。GDB は単にエラーがどこにあるのか混乱し、ベクター行に貼り付けました...うーん。ただし、STL の使用を考えれば驚くことではありません。

また、ベクトルを動的に割り当てるとヒープが台無しになる可能性があると言う人には、なぜですか? これは意味がありません; すべてのオブジェクトを動的に割り当てるかどうかは気にしません。そうしても問題は発生しません。ヒープ オブジェクトとスタック オブジェクトを混在させると、過去に多くの問題が発生しました。物事を一貫して機能させる唯一の方法は、すべてのヒープ オブジェクトを使用することです。

ただし、スタック オブジェクトとヒープ オブジェクトがどのように共存できるかを説明できる人がいれば、喜んでそれを聞いてみたいと思います。Objective-C は完全に理にかなっていますが、C++ の無意味なオブジェクトの扱いはほとんど常に問題を引き起こします。残念ながら、C++ を使用する必要があるため、多くの選択肢がありません...

于 2011-02-19T23:00:18.050 に答える
2

この呼び出しを行う前に、他の何かがヒープを破損している可能性があります。valgrindまたは同等のもので実行してみましたか？

于 2011-02-16T17:27:55.993 に答える