GaitGenerator.cppでメモリアクセス違反

[fkanehiro]

@snozawa さん、
testGaitGenerator --test0
とすると、
https://github.com/fkanehiro/hrpsys-base/blob/master/rtc/AutoBalancer/GaitGenerator.cpp#L213
で、step_count_listの長さが6であるのに対して、6以上のインデックスでのアクセスが行われるようです。

[snozawa]

ありがとうございます、確認します。
ところでこれはvalgrindか何かで確認されましたでしょうか。

[fkanehiro]

AddressSanitizerという機能で検出しました。
http:https://qiita.com/watson1978/items/60e618c2c48dc7a19868

[snozawa]

ありがごとうございます、参考になります。

[snozawa]

度々すいません、AddressSanitizer（とclang）でhrpsys-baseをビルドするときはどのようにされてますか？

[fkanehiro]

CMAKE_CXX_FLAGS_XXやCMAKE_C_FLAGS_XXに手動で-fsanitize=addressを追加しています。
コンパイラはg++で大丈夫です。

[snozawa]

ありがとうございます、習性前はエラーがでて、習性後にでないことを確認しました。

[snozawa]

#1159
で解決しました。
ご確認いただけますと幸いです。

[fkanehiro]

ありがとうございます。
直ったようです。

[k-okada]

すごいですね．これ．知りませんでした．
euslispのかなり長い間見逃されていたバグを見つけた気がします．
euslisp/EusLisp#243

[k-okada]

@ban-masa @future731 これです．

[ban-masa]

@k-okada
岡田先生
この機能は実行時にのみ検知するものだと理解しているのですが、
hrpsysをこの機能込みでbuildしてシミュレータ上でバグが発生する状況を試して検知させるという使用法になるのでしょうか。

[k-okada]

そうでした．これも実行しないとダメですね．
バグが発生する状況で検出できないとちょっと残念ですが，
期待したいのは２足状態でバグはでないけど，変なコードになっている時に検出できると嬉しいでうね．ということでした．
１回かけてみてどういう結果になるか，というのが知りたい所．

以下の方法に加えて，
https://scan.coverity.com/projects/hrpsys/
みたいな方法もあるみたいです．１，２日経つと結果が見えるはず．

k-okada@p51s:/tmp/test$ cat hoge.cpp 
#include <stdio.h>
#include <stdlib.h>

int main() {
  int hoge[3];
  int hoge2[3];
  for (int i = 0; i < 4;i++) {
    hoge[i] = i;
  }
  int *fuga;
  fuga = (int *)malloc(100);
}
k-okada@p51s:/tmp/test$ cat Makefile 
all: cat gcc valgrind # clang

cat:
	cat hoge.cpp

gcc:
	g++ -fsanitize=address -o hoge hoge.cpp
	./hoge || echo "OK"

clang:
	rm -fr /tmp/scan-build-*
	scan-build clang++ -o hoge hoge.cpp
	PYTHONPATH=/usr/lib/llvm-3.8/share/scan-view/:$PYTHONPATH scan-view /tmp/scan-build*

valgrind:
	gcc -g -o hoge hoge.cpp
	valgrind --tool=memcheck --leak-check=full ./hoge || echo "OK"

k-okada@p51s:/tmp/test$ make
cat hoge.cpp
#include <stdio.h>
#include <stdlib.h>

int main() {
  int hoge[3];
  int hoge2[3];
  for (int i = 0; i < 4;i++) {
    hoge[i] = i;
  }
  int *fuga;
  fuga = (int *)malloc(100);
}
g++ -fsanitize=address -o hoge hoge.cpp
./hoge || echo "OK"
=================================================================
==7935==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe06d1294c at pc 0x000000400936 bp 0x7ffe06d12900 sp 0x7ffe06d128f0
WRITE of size 4 at 0x7ffe06d1294c thread T0
    #0 0x400935 in main (/tmp/test/hoge+0x400935)
    #1 0x7f7bcc71682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #2 0x400788 in _start (/tmp/test/hoge+0x400788)

Address 0x7ffe06d1294c is located in stack of thread T0 at offset 44 in frame
    #0 0x400865 in main (/tmp/test/hoge+0x400865)

  This frame has 1 object(s):
    [32, 44) 'hoge2' <== Memory access at offset 44 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 main
Shadow bytes around the buggy address:
  0x100040d9a4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100040d9a4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100040d9a4f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100040d9a500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100040d9a510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100040d9a520: 00 00 00 00 f1 f1 f1 f1 00[04]f4 f4 f3 f3 f3 f3
  0x100040d9a530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100040d9a540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100040d9a550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100040d9a560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100040d9a570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==7935==ABORTING
OK
gcc -g -o hoge hoge.cpp
valgrind --tool=memcheck --leak-check=full ./hoge || echo "OK"
==7943== Memcheck, a memory error detector
==7943== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7943== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7943== Command: ./hoge
==7943== 
==7943== 
==7943== HEAP SUMMARY:
==7943==     in use at exit: 100 bytes in 1 blocks
==7943==   total heap usage: 1 allocs, 0 frees, 100 bytes allocated
==7943== 
==7943== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7943==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7943==    by 0x4005D5: main (hoge.cpp:11)
==7943== 
==7943== LEAK SUMMARY:
==7943==    definitely lost: 100 bytes in 1 blocks
==7943==    indirectly lost: 0 bytes in 0 blocks
==7943==      possibly lost: 0 bytes in 0 blocks
==7943==    still reachable: 0 bytes in 0 blocks
==7943==         suppressed: 0 bytes in 0 blocks
==7943== 
==7943== For counts of detected and suppressed errors, rerun with: -v
==7943== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[ban-masa]

hrpsysをAddressSanitizer付きでbuildしてシミュレータ上で試そうと思ったのですが、AddressSanitizer付きだとChoreonoidが使えないということに気がついたので報告しておきます。

今回の自分の気づいたバグの発生環境はハンドに力を与える必要があったため、インタラクティブに力を与えられるChoreonoidを使おうとしたのですが、どうもhrpsysの生成するdllがdlopenできなくなり正常に動作しないようです。（dllを使わないhrpsys-simulatorは大丈夫でした）

[k-okada]

rtcだけをためすのであれば，hrpsys-simulator で:angle-vector送れば状況は再現できると理解しているんだけど，それでいいよね．

…

-- ◉ Kei Okada 2018年11月8日(木) 17:22 Bando Masahiro <[email protected]>:

hrpsysをAddressSanitizer付きでbuildしてシミュレータ上で試そうと思ったのですが、AddressSanitizer付きだとChoreonoidが使えないということに気がついたので報告しておきます。 今回の自分の気づいたバグの発生環境はハンドに力を与える必要があったため、インタラクティブに力を与えられるChoreonoidを使おうとしたのですが、どうもhrpsysの生成するdllがdlopenできなくなり正常に動作しないようです。（dllを使わないhrpsys-simulatorは大丈夫でした） — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1154 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeG3D1n__4VI2xM0rMUW8GyRIl3wjzjks5us-nAgaJpZM4N9E8i> .

[k-okada]

@ban-masa 結果らしいものがでたようです↓　見方がよくわからないけど，変更したコード部分はここに入っているのかな？
https://scan4.coverity.com/reports.htm#v39896/p16026/fileInstanceId=54696103&defectInstanceId=10019347&mergedDefectId=326318

[ban-masa]

岡田先生

今回問題にしていた部分は

hrpsys-base/rtc/Stabilizer/ZMPDistributor.h

Lines 134 to 141 in 7263626

	for (size_t i = 0; i < cs.size(); i++) {
	if (cs[i]) {
	for (size_t j = 0; j < vs[i].size(); j++) {
	tpos = ee_pos[i] + ee_rot[i] * hrp::Vector3(vs[i][j](0), vs[i][j](1), 0.0);
	tvs.push_back(tpos.head(2));
	}
	}
	}

の部分で、csとvsのサイズが違うと配列外アクセスをするというものでした。
vsを四脚分正しく設定すれば防げるのですが、vsとcsのサイズの違いをチェックする仕様にはなっていないので気づかずにセグフォを起こしてしまいました。

coverity scanの方で該当部分をチェックしてみましたが、残念ながら検出されてはいないようです。
ただ、他にも怪しい部分が検知されているように見えるのでそちらもこれからチェックしてみます。