C/C++でのメモリリーク検出方法 〜AddressSanitizer, Valgrind, mtrace〜 - kivantium活動日記
C/C++でプログラムを書いているときに遭遇する厄介なバグの一つがメモリリークです。 今回はメモリリークを検出するのに使えるツールの使い方について書きます。 AddressSanitizer コンパイルオプションをつけるだけで使えて出力も見やすいのでおすすめです。 AddressSanitizerはGCC 4.8以降かLLVM 3.1以降で使うことができます。 コンパイル時にオプションをつけるだけでメモリリークを検出してくれます。（若干実行時間が長くなります） 以下のメモリリークのあるプログラム leak.cpp を例に使い方を説明します。 int main() { int *a = new int[10]; } newで作った動的配列をdeleteしていないのでメモリリークになります。 g++ -fsanitize=address -fno-omit-frame-pointer -g l
VSCode + MinGW-64 で C++ のコードをビルド＆デバッグするまで - Qiita
みなさまこんにちは。ハーツテクノロジーの山崎です。この記事は仕事の中で得たられた知見によって書かれています。 どんな話？ プログラマのみなさんはすでに利用しているひとも多いと思われる超絶便利テキストエディタ「Visual Studio Code」の話です。ここでは略して「VSCode」と書きます。 このエントリでの話題は、 VSCode で C++ のビルドとデバッグができます。しかもフリーのC++である「MinGW-64」を使って！！ そんな話。実際に C++ のコードをデバッグしているところを見たほうが早いですね。こんな感じ。 できるようになるには、大きく２つのステップがあって。 1, MinGW-64 のインストール 2, VSCode の設定 この２つです。この２つを乗り越えればハッピープログラミングライフ（なにそれ？）が待っています。以下をご覧くださいませー。 1, MinGW-
VSCodeでC/C++開発環境を整えてみる(MinGW(gcc)編) : OFF-SOFT.net
先の "hello.cpp" の編集を終えたら、以下のように表示されているかと思います。 上記の緑の波線は、エラー表記となっています。 これは、C/C++ for Visual Studio Code(Extension) によって簡易エラー表記されているものですので、 これはこれで、先のExtensionが間違いなく動作していることでもあります。 上記の緑の波線は、実際にはエラーではないので、C/C++ for Visual Studio Code(Extension) が 正しく判断できていないことは、ソースコードからもわかります。 では、C/C++ for Visual Studio Code(Extension) が正しく判断できるように設定し、先の緑の波線のエラー表記を解除してみます。 C/C++ for Visual Studio Code のデフォルト設定ファイルを作成する。
gitpod で graphics + C++ 開発環境を整備したいのメモ - Qiita
最近流行り? のクラウド開発環境 gitpod 便利ですね. Gitpodが最強過ぎる件について https://qiita.com/mouse_484/items/394a4984f749cc201422 gitpodでjupyternotebookの開発環境を作る https://qiita.com/ymmmtym/items/14de67dc64b3c47704e8 クラウドIDE「Gitpod」を試してみたら予想以上に使えそうだった https://qiita.com/kai_kou/items/40a7a579f1bce31d6a16 github アカウントがあればすぐ試せます. gitpod が他のクラウド IDE サービスと異なるところは, Docker による仮想環境に直接アクセスできるところです. 2019 年 11 月 4 日時点では, gitpod が動いている仮想
gdbを使ってコアダンプの原因を解析 - それが僕には楽しかったんです。
コアダンプは嫌いだ。 大学やその他情報系専門科のある学校に通ったことがある人が一度は触ったことがあるであろう、C言語。 こいつは近年の言語に比べてものすごく面倒くさい書き方をするし、手間もかかる。 中でも最悪なのが「コアダンプ」の文字。 これは、多くのC言語ユーザを苦しめてきただろう。 一応エラーの部類に入ると思うが、こいつはどこで問題が起きているか普通は出力してくれないから直すのがすごく大変。 というわけで、今回はコアダンプの原因をgdbというデバッガを使用して解析してみる(※linuxユーザ向け) それでは解析の準備 これはこの前自分が実際にコアダンプを発生させてしまったコード。 このファイルをここでは「quicksort.c」とする。 #include<stdio.h> void quicksort(int array[],int left_index,int right_index
gdb の使い方・デバッグ方法まとめ
たとえば、変数 var の値を2進数で表示したい場合は、次のように指定します。 (gdb) p/t var 一覧表示 whatis 変数の型を調べる。 info b 今設定しているブレークポイントの一覧を表示 セグメントフォルトをした後に利用すれば、どの関数で発生したか確認できます。 info stack 関数の呼び出しスタックの一覧を表示 info Thread 存在しているスレッドの一覧を表示 異なるアドレスにおける処理継続 以下のコマンドを使用することで、ユーザが選択したアドレスにおいて実行を継続させることができます jump linespec linespecで指定される行において、実行を再開 jump *address addressで指定されるアドレスにある命令から、実行を再開 アドレスが分かっている場合のメモリリーク出力 xはhexの意味です。 (gdb) p (char*)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
