Armadilloフォーラム

笹山です。

> 1.デバッグ情報入りのライブラリを/usr/lib以下に配置(教えて頂いた方法)
> valgrindを実行するとやはり最初と同じエラーが発生して起動できませんでした。

こちらでも valgrind 3.6.0 で同様の現象が発生することを確認しました。
何故かデバッグ情報のCRC値が一致せずエラーとなっているようです。

[root@armadillo420-0 (ttymxc1) ~]# valgrind --verbose ls
 : 一部省略
--1336-- Valgrind library directory: /usr/lib/valgrind
--1336-- Reading syms from /bin/busybox (0x8000)
--1336--    object doesn't have a symbol table
--1336-- Reading syms from /lib/ld-2.11.3.so (0x4000000)
--1336--   Considering /lib/ld-2.11.3.so ..
--1336--   .. CRC mismatch (computed e610fdd3 wanted 000088e8)
--1336--   Considering /usr/lib/debug/lib/ld-2.11.3.so ..
--1336--   .. CRC mismatch (computed 785b88e8 wanted 000088e8) # CRC不一致(xxxx88e8 は一致?)
--1336--    object doesn't have a symbol table

エラーの原因は特定できていないのですが、
valgrind は armv7 以降のみをサポートしている為、
armv5 である Armadillo-400シリーズでは正常に動作しないようです。

> 2. デバッグ情報入りのライブラリを/lib以下に配置
> valgrindは/usr/libではなくて/libを見ているのではないかと思い、
> /lib以下にデバッグ情報入りのライブラリを配置したイメージを作成しましたが、
> カーネルパニックを起こしてlinux自体が起動しませんでした。(起動ログを添付しています)

大変失礼しました。
先の回答で、*-dbg パッケージは デバッグ情報が strip されていないものと記載していたのですが、これは誤りでした。
正しくは *-dbg パッケージは strip されたデバッグ情報のみですね。
libc6 + libc6-dbg で デバッグ情報が strip されていないもの相当になります。

その為、上記の手順でlibc6関連のライブラリを、libc6-dbg に置き換えると
カーネルパニックが発生します。

> 3. デバッグ情報入りのファイルを/usr/lib/debug以下に配置
> libc6-dbg_2.11.3-4_armel.debのパッケージ情報を見るとファイルのインストール先は/usr/lib/debug以下になっているので、
> それに合わせてファイルを配置したイメージで、LD_LIBRARY_PATHに/usr/lib/debug/libと/usr/lib/debug/usr/libを追加して
> valgrindを実行しましたが、1.と同じ結果になりました。

/usr/lib/debug 以下に *-dbg パッケージを配置すると、valgrind は自動で参照してくれます。
その為 valgrind では LD_LIBRARY_PATH の設定は不要です。

> 教えて頂いた方法を試してみましたが残念ながらうまくいきませんでした。
> 以下にいろいろ試した結果を書いています。何か他にいい方法はありませんでしょうか。

参考までに valgrind 以外でメモリリークをチェックできる mtrace の動作確認方法を以下に記載します。

■ mtrace 動作確認方法

valgrind と違いチェック対象のアプリに改造が必要ですが、
Armadillo-400シリーズで動作確認が行えています。

まずアプリケーションでリークチェックを行う範囲を mtrace(), muntrace() 関数で指定します。

サンプルコード: mtrace-test.c

#include <stdlib.h>
#include <mcheck.h> /* mtrace, muntrace用 */
 
int main(int argc, char* argv[]) {
        char* buf;
        mtrace(); /* チェック開始 */
        buf = (char*)malloc(10);
        muntrace(); /* チェック終了 */
        return 0;
}

アプリにデバッグ情報を付加してコンパイルします。

[ATDE4]$ arm-linux-gnueabi-gcc mtrace-test.c -o mtrace-test -g

armadillo 上で MALLOC_TRACE に mtrace の結果ログを格納するパスを指定し、 mtrace-test を実行します。

armadillo# MALLOC_TRACE=./log ./mtrace-test

log ファイルが作成されますので、ATDE4 上の mtrace コマンドでログを解析します。
解析結果から mtrace-test.c 6行目の malloc した領域が free されていないことがわかります。

atmark@atde4:~/mtrace$ mtrace mtrace-test log
 
Memory not freed:
-----------------
           Address     Size     Caller
0x0000000000011380      0xa  at /home/atmark/mtrace/mtrace-test.c:6

注意点としまして、C++ の new / delete によるメモリリークも mtrace でチェックができますが、
チェックでひっかかるアドレスが libstdc++.so になる関係上、
コード内の、どのインスタンスが delete されていないかまでは判別ができません。