の使用中に発生するプログラムのスタック破損バグであると思われるものに対処していますQNetworkAccessManager
。完全なソース コードはこちらから入手できます。
ログ出力から判断すると、バグはcalendar.cppの 44 行目の非同期リクエストの後にトリガーされると推測しています。これについて確固たる証拠はありません。ほとんどの場合、45 行目のメッセージが最後のログ メッセージであることだけに気付きました。
39 ~ 46 行目は次のとおりです。
void Calendar::update()
{
// Start calendar download asynchronously. After retrieving the
// file, parseNetworkResponse will take over.
Logger::instance()->add(CLASSNAME, "Fetching update for 0x" + QString::number((unsigned)this, 16) + "...");
_naMgr.get(QNetworkRequest(_url));
Logger::instance()->add(CLASSNAME, "Update request for 0x" + QString::number((unsigned)this, 16) + " was filed.");
}
この HTTP GET リクエストは、のシグナルCalendar::parseNetworkResponse
に接続されているスロットによって処理されます。170 ~ 174 行を次に示します。_naMgr
finished
void Calendar::parseNetworkResponse(QNetworkReply* reply) {
// TODO: we suspect that sometimes a SIGSEGV occurs within the bounds
// of this function. We'll remove the excessive log calls when we've
// successfully tracked down the problem.
Logger::instance()->add(CLASSNAME, "Got update response for 0x" + QString::number((unsigned)this, 16) + ".");
45 行目のログ メッセージがクラッシュ後のログに最後に表示されない場合でも、ログには常に更新要求があり、その後に 174 行目のログ メッセージが続くことはありません。 HTTP GET 要求は、ここで物事を台無しにしている可能性があります。GET リクエストが提出される URL は正しいようです。
メモリ破損が関係していると思われる理由の 1 つは、入力カレンダーのリストとインターネット接続の状態が同じままであるにもかかわらず、バグが一貫してポップアップしないことです。(少なくとも 2 つのカレンダーでバグを引き起こすことができます。) さらに、障害点について詳しく調べようとすると、この GCC 出力が表示されました。のメモリ チェッカーから出力valgrind
を収集して追加情報を収集したはずですが、現時点では近くに Linux がインストールされていません。
このバグは、Qt のネットワーク ライブラリを誤って使用したことに関連している可能性がありますか? 問題の原因について他に何か理論はありますか? スタック破損の可能性に対処するのはこれが初めてであり、空き時間にこのソロの趣味プロジェクトを行っているため、これらの問題に対処する方法を教えてくれる人がいません。