gcc+gdbによるプログラムのデバッグ 第1回 ステップ実行、変数の操作、ブレークポイント
しかし、ブレークポイントという機能はデバッガの手助けなしでは実現できません。 ブレークポイントとはプログラムの強制一時停止を行うポイントで、実行中のプログラムがブレークポイントに遭遇するとプログラムは一時停止され、デバッガによるプログラムへの介入を行えるようになります。 ブレークポイントは次のような場所に設定できます。 指定した行番号のプログラムを実行しようとする瞬間 関数を呼び出した瞬間 その他、C++などでは「例外が発生した瞬間」などにもブレークポイントを設定することができます。 行番号ブレーク ブレークポイントとしてよく使用されるのは、「プログラムの特定の位置」です。 例として、bubblesort.cプログラムのsort関数内で、隣り合う二つの要素を比較している箇所にブレークポイントを設定してみます。 25|/* bubble sort */ 26|void sort(int *a
GDBでSegmentation Faultの原因を突き止める - /* Grid Thinking */
Linuxのプログラムをデバッグするとき、一番困ることはあの有名の「Segmentation Fault」ですね。 プログラムが膨大でマルチプロセス等を使っていたら、どこで問題を起こしているのかすらわからないです。 本編はLinuxのCore Dump機能で問題発生行を特定する方法を紹介します。 まず、前提としてはSegmentation Faultは再現できること。（当たり前ですよね） 下記のプログラムを例とします。#include<stdio.h> #include<string.h> #define DATA "TEST" char mngfile[2][50]; int main() { memset( mngfile, '\0', sizeof(mngfile) ); GetMngFile(mngfile); return 0; } int GetMngFile( mngfile
メモリの情報取得 | LinuxC
システムのメモリの情報取得 まず、システムが知っているメモリ情報を取得しましょう。 例えば、物理メモリ量やSWAPのメモリ量等です。時々ですが、こういう情報が欲しい場合がありますね。 sysinfo(2)のmanページを見ればどういった情報が取得できるかが分かります。 Linux 2.3.23 (i386)、2.3.48 (全てのアーキテクチャ) からは構造体は struct sysinfo { long uptime; /* Seconds since boot */ unsigned long loads[3]; /* 1, 5, and 15 minute load averages */ unsigned long totalram; /* Total usable main memory size */ unsigned long freeram; /* Available me
Visual StudioでLinux向けにMakefileプロジェクトを作ってリモートビルドする – Bakulog
初歩的なとこで突っかかったのでメモ程度に。 本記事ではVisual StudioのプラグインであるVisual C++ for Linux Developmentに最近追加された機能を紹介します。 まずVisual C++ for Linux Developmentとは何かという話ですが、これは名前の通りVisual StudioでLinux向け開発をサポートするプラグインです。 プラグイン自体は以前から公開されていて、クロスコンパイルに関する方法の解説記事が上がっていたりします。 Visual C++ for linux Development を軽く使ってみた Visual C++ for Linux Developmentつかってみようとしたらハマったけど動いた さて。ここからが本題ですが、2016年8月19日に同プラグインではMakefileプロジェクトが新たにサポートされました。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
