Closed k-okada closed 9 years ago
k-okada
commented
10 years ago たしかにそうですね． ところで，「いくらかましになる」というのはまだ残っているでしょうか？ rostest roseus test-add-two-ints.launch で，１，２分service callを呼び続けるようにしたんですが，解決しいるように見えますが まだ残っている問題があれば教えてください．
(deftest test-add-two-ints-many
(ros::wait-for-service "add_two_ints")
(dotimes (i 2000)srvをなぜ導入したかわからなくなっていますが。 srvなしで動くと思います。リークもしていないようです。
Index: roseus.cpp
===================================================================
--- roseus.cpp (リビジョン 4419)
+++ roseus.cpp (作業コピー)
@@ -1033,9 +1033,8 @@
vpush(response._message); // to avoid GC, its important
ServiceClientOptions sco(ros::names::resolve(service), request.__getMD5Sum(), persist, M_string());
ServiceClient client = s_node->serviceClient(sco);
- ServiceClient* srv = new ServiceClient(client);
// NEED FIX
- bool bSuccess = srv->call(request, response, request.__getMD5Sum());
+ bool bSuccess = client.call(request, response, request.__getMD5Sum());
vpop(); // pop response._message
vpop(); // pop request._message
if ( ! bSuccess ) {追加されたファイルをwaitやformatしないように改造してしばらく動かし、 メモリリークがなさそうなことを確認しました。 srvなしで良さそうですね。
上で「いくらかましになる」と書いたのは、操縦プログラムではリークの要因がservicecallだけではなさそうだからです。 たとえば、roseusで_ri_を作ってから、
(do-until-key (send *tfl* :lookup-transform "/RLEG_LINK1" "/BODY" (ros::time)))
(do-until-key (send *tfl* :lookup-transform "/RLEG_LINK2" "/BODY" (ros::time)))などとtfを何種類か取り続けると、どんどんメモリを消費するようになることがあります。
k-okada
commented
10 years ago [r4422]でコミットしました．
test-tf.l にメモリーリークするテストプログラムをつくてもらえると助かります．
k-okada
commented
10 years ago コミット権を持っていませんでした。
こんな感じでどうでしょうか。 高頻度で呼んでいてちょっと普通のtfの使い方ではないのですが、 time overで切られるまでにメモリ使用量はRSSで1.7GBくらいまで増えます。
watch -n 1 'ps aux | grep eus' などとすると、メモリ使用量が増えていくのがわかると思います。
Index: test-tf.l
===================================================================
--- test-tf.l (リビジョン 4422)
+++ test-tf.l (作業コピー)
@@ -49,6 +49,28 @@
(assert (send l :lookup-transform "MANDALAY" "JUPITER" tm))
)
+(deftest test-tf-many ()
+ (setq l (instance ros::transform-listener :init))
+ (unix:sleep 1)
+ (setq tm (ros::time))
+ (setq ret (send l :wait-for-transform "/MANDALAY" "/TOKYO" tm 1))
+ (warning-message 2 "wait-for-transform at ~A returns ~A~%" tm ret)
+ (setq j 0)
+ (while (< j 20)
+ (incf j)
+ (let ((i 0))
+ (while (< i 100000)
+ (progn
+ (incf i)
+ (send l :lookup-transform "MANDALAY" "JUPITER" (ros::time)))))
+ (warning-message 2 "switch target to /TOKYO~%")
+ (let ((i 0))
+ (while (< i 100000)
+ (progn
+ (incf i)
+ (send l :lookup-transform "MANDALAY" "TOKYO" (ros::time)))))
+ (warning-message 2 "switch target to /JUPITER~%")))
+
(run-all-tests)
(exit)
Index: test-tf.launch
===================================================================
--- test-tf.launch (リビジョン 4422)
+++ test-tf.launch (作業コピー)
@@ -1,4 +1,5 @@
<launch>
<node name="tf_publisher" pkg="tf" type="static_transform_publisher" args="1 0 0 0 0 0 /MANDALAY /JUPITER 10" />
+ <node name="tf_publisher2" pkg="tf" type="static_transform_publisher" args="1 2 3 0.1 0.2 0.3 /JUPITER /TOKYO 10" />
<test test-name="eustf" pkg="roseus" type="roseus" args="$(find roseus)/test/test-tf.l" />
</launch>そのままコミットしてみました。jenkins等は大丈夫でしょうか？
僕の環境では、600MBほどメモリを取られますが、どんどん増える感じでは無く、 横ばいです。12.04/64bit/fturtleです。
また、deftestしたところ単体で動かすと20MBほどになって、これもメモリは増えません。 この問題とは別に、roseusのテストでメモリを消費しているようです。
k-okada
commented
10 years ago 別のPCで試してみたところ、一気にメモリが確保されますが確かに増えませんでした。 リークしていそうなPCの環境を調べてみます。
k-okada
commented
10 years ago 僕の環境では
k-okada 24893 95.9 3.9 1379648 641248 pts/0 Rl+ 08:57 0:38 /home/k-okada/ros/fuerte/jsk-ros-pkg/euslisp/jskeus/eus/Linux64/bin/irteusglとなります．これって1.3Gメモリを取られると判断するのでよいでしょうか？これ以上は増えなさそうです．
ここで，eustf.lで
(:lookup-transform
(target-frame source-frame time)
(let (ret)
(setq ret (ros::eustf-lookup-transform cobject
target-frame source-frame
(send time :sec-nsec)))
(return-from :lookup-transform ret)としてみると，800Mぐらいで安定．make-coordsかquaternion2matrixがわるい？とおもって，
(return-from :lookup-transform
(make-cascoords :pos (float-vector
(* 1000.0 (elt ret 0))
(* 1000.0 (elt ret 1))
(* 1000.0 (elt ret 2)))
:rot
(user::quaternion2matrix
(float-vector (elt ret 3)
(elt ret 4)
(elt ret 5)
(elt ret 6)))
:name target-frame))とすると，これも800Mで安定．何が違うでしょうか？roseusとして立ち上げると
EusLisp 8.26(r642M 916)
roseus(r4423M)というメッセージがでますがこれのr642というのがeusのリビジョンr4423がroseusのリビジョンです． すくなくともeusのリビジョンは同じ事を確認したいです．
k-okada
commented
10 years ago 1.3Gの方は割り当てられている仮想メモリで、実メモリに確保されている容量は641248だと思います。 ここを見て大体600Mなどと判断していました。
リークについてですが、この環境では古いeusを使っていたようです。 リークしていたマシンは EusLisp 8.26(r628M 903) for Linux64 created on tnakaoka-ThinkPad-T430s(2013年 5月 1日 水曜日 20:09:58 JST) roseus ;; loading roseus(r4422M) on euslisp((8.26 tnakaoka-ThinkPad-T430s 2013年 5月 1日 水曜日 20:09:58 JST r628M 903)) でした。
svn upして岡田先生と同じバージョンに更新すると、こちらもメモリ消費量は増えなくなりました。 5月に入ってから修正されていたようです。おさわがせしました。
k-okada
commented
10 years ago 最近MAXSTACKとかを変えたからかな，と思ったんだけど， euslisp r628 -> r642 irteus r903 -> r916 の間に重要そうなコミットはないんだよね．なんだったんだろうか？ https://sourceforge.net/p/euslisp/code/642/log/?path= https://sourceforge.net/p/jskeus/code/918/log/?path=
k-okada
commented
10 years ago たしかに、本体に手を加えるようなコミットはなさそうです。
ところで、以下を実行してみるとどうでしょうか。 別のシェルでroslaunch roseus test-tf.launchとしておく必要があります。 svn upした環境でも消費量が増えていき、終わるまでに2GBくらい消費します。
関数から出るときの返り値がデバッグ用に保管されている、などでしょうか。 メモリリークしにくいような、euslispの書き方などあるのでしょうか。
後になればなるほど、gcの頻度が落ちているように見えます。 gcが出るとしばらくはメモリの増加が落ち着きますが、しばらくするとまた増えていきます。 一旦実行がおわっても、(test-tf-many-loop)とすると無限に増えていきそうです。 sys:gcは同じスコープ内のgcしかしない、などあるのでしょうか。
#!/usr/bin/env roseus
(ros::roseus "test-tf")
(setq sys::*gc-hook* #'(lambda (a b) (format *error-output* ";; gc ~A ~A~%" a b)))
(setq *l* (instance ros::transform-listener :init))
(defun test-tf-many ()
(unix:sleep 1)
(setq tm (ros::time))
(setq ret (send *l* :wait-for-transform "/MANDALAY" "/TOKYO" tm 1))
(warning-message 2 "wait-for-transform at ~A returns ~A~%" tm ret)
(let ((j 0))
(while (< j 2)
(incf j)
(let ((i 0))
(while (< i 100000)
(incf i)
(send *l* :lookup-transform "MANDALAY" "JUPITER" (ros::time))))
(warning-message 2 "switch target to /TOKYO~%")
(let ((i 0))
(while (< i 100000)
(incf i)
(send *l* :lookup-transform "MANDALAY" "TOKYO" (ros::time))))
(warning-message 2 "switch target to /JUPITER~%")
)))
(defun test-tf-many-loop ()
(let ((i 0) a)
(while (< i 10)
(incf i)
(setq a (test-tf-many))))
t
)
(test-tf-many-loop)
あまり良く分かっていなく申し訳ないのですが、 sys::gcしたときに出る数字二つのうち1つ目は空いているワード数、2つ目は全体のワード数ということで、 使っていないメモリを無駄に確保していることになっている気がします。
sys::roomで一番下のholesが大半を占めていますが、これだけ小文字なので空きスペースということのようです。
tnakaoka 5732 8.3 12.4 3066500 2012468 pts/15 Sl+ 11:40 1:45 /home/tnakaoka/ros/fuerte/jsk-ros-pkg/euslisp/jskeus/eus/Linux64/bin/irteusgl (pushnew "/home/tnakaoka/ros/fuerte/jsk-ros-pkg/roseus/euslisp/" *load-path* :test #'equal) roseus.l eustf.l actionlib.l roseus-utils.l ./tf.l
1.irteusgl$ sys::gc
;; gc 304881945 305601216
(304881945 305601216)
5.irteusgl$ sys:memory-report
buddy size free total total-size wanted wanted-size
1 3 62553 172955 518865 240183096 720549288
2 6 9472 29981 179886 36044346 216266076
3 9 3145 18637 167733 12019060 108171540
4 15 4140 4824 72360 16001743 240026145
5 24 207 422 10128 363 8712
6 39 150 307 11973 240 9360
7 63 47 282 17766 284 17892
8 102 166 201 20502 278 28356
9 165 19 46 7590 47 7755
10 267 8 56 14952 64 17088
11 432 4 28 12096 37 15984
12 699 2 13 9087 23 16077
13 1131 5 11 12441 17 19227
14 1830 4 7 12810 13 23790
15 2961 1 7 20727 12 35532
16 4791 63555 63556 304496796 3 14373
17 7752 0 2 15504 2 15504
18 12543 0 0 0 0 0
19 20295 0 0 0 0 0
20 32838 0 0 0 0 0
21 53133 0 0 0 0 0
22 85971 0 0 0 0 0
23 139104 0 0 0 0 0
24 225075 0 0 0 0 0
25 364179 0 0 0 0 0
26 589254 0 0 0 0 0
27 953433 0 0 0 0 0
28 1542687 0 0 0 0 0
29 2496120 0 0 0 0 0
30 4038807 0 0 0 0 0
31 6534927 0 0 0 0 0
32 10573734 0 0 0 0 0
33 17108661 0 0 0 0 0
34 27682395 0 0 0 0 0
35 44791056 0 0 0 0 0
36 72473451 0 0 0 0 0
37 117264507 0 0 0 0 0
38 189737958 0 0 0 0 0
39 307002465 0 0 0 0 0
context big_alloc small_alloc
t
8.irteusgl$ sys::room
OBJECT 515 cells 2538 words 19KB
CONS 105242 cells 315726 words 2466KB
QUEUE 0 cells 0 words 0KB
PROPERTIED-OBJECT 0 cells 0 words 0KB
SYMBOL 11993 cells 107937 words 843KB
FOREIGN-POD 0 cells 0 words 0KB
PACKAGE 108 cells 1620 words 12KB
STREAM 1 cells 6 words 0KB
FILE-STREAM 3 cells 27 words 0KB
BROADCAST-STREAM 0 cells 0 words 0KB
TEXTWINDOWSTREAM 0 cells 0 words 0KB
IO-STREAM 1 cells 6 words 0KB
SOCKET-STREAM 0 cells 0 words 0KB
METACLASS 275 cells 2475 words 19KB
VECTORCLASS 9 cells 135 words 1KB
CSTRUCTCLASS 7 cells 105 words 0KB
READTABLE 4 cells 24 words 0KB
ARRAY 4 cells 60 words 0KB
IMAGE-2D 0 cells 0 words 0KB
SINGLE-CHANNEL-IMAGE 0 cells 0 words 0KB
BITMAP-IMAGE 0 cells 0 words 0KB
GRAYSCALE-IMAGE 0 cells 0 words 0KB
INDEX-COLOR-IMAGE 0 cells 0 words 0KB
MULTI-CHANNEL-IMAGE 0 cells 0 words 0KB
SPLIT-COLOR-IMAGE 0 cells 0 words 0KB
COLOR-IMAGE 0 cells 0 words 0KB
COLOR-IMAGE16 0 cells 0 words 0KB
COLOR-IMAGE24 0 cells 0 words 0KB
COLOR-IMAGE32 0 cells 0 words 0KB
THREAD 0 cells 0 words 0KB
PORT-SELECTOR 1 cells 6 words 0KB
COORDINATES 2 cells 12 words 0KB
CASCADED-COORDS 0 cells 0 words 0KB
FACESET 0 cells 0 words 0KB
BODY 0 cells 0 words 0KB
SENSOR-MODEL 0 cells 0 words 0KB
BUMPER-MODEL 0 cells 0 words 0KB
CAMERA-MODEL 0 cells 0 words 0KB
SPHERE 0 cells 0 words 0KB
VIEWING 0 cells 0 words 0KB
PROJECTION 0 cells 0 words 0KB
VIEWING2D 0 cells 0 words 0KB
PARALLEL-VIEWING 0 cells 0 words 0KB
PERSPECTIVE-VIEWING 0 cells 0 words 0KB
COORDINATES-AXES 0 cells 0 words 0KB
POLYGON2D 0 cells 0 words 0KB
CIRCLE2D 0 cells 0 words 0KB
BODYSET 0 cells 0 words 0KB
BODYSET-LINK 0 cells 0 words 0KB
BVH-LINK 0 cells 0 words 0KB
SCENE-MODEL 0 cells 0 words 0KB
CASCADED-LINK 0 cells 0 words 0KB
ROBOT-MODEL 0 cells 0 words 0KB
BVH-ROBOT-MODEL 0 cells 0 words 0KB
RIKIYA-BVH-ROBOT-MODEL 0 cells 0 words 0KB
TUM-BVH-ROBOT-MODEL 0 cells 0 words 0KB
CMU-BVH-ROBOT-MODEL 0 cells 0 words 0KB
POINTCLOUD 0 cells 0 words 0KB
GLVERTICES 0 cells 0 words 0KB
TF-CASCADED-COORDS 0 cells 0 words 0KB
VIEWPORT 0 cells 0 words 0KB
BARRIER-SYNCH 0 cells 0 words 0KB
SYNCH-MEMORY-PORT 0 cells 0 words 0KB
LINE 0 cells 0 words 0KB
EDGE 0 cells 0 words 0KB
WINGED-EDGE 0 cells 0 words 0KB
PLANE 3 cells 18 words 0KB
POLYGON 0 cells 0 words 0KB
FACE 0 cells 0 words 0KB
HOLE 0 cells 0 words 0KB
SEMI-SPACE 0 cells 0 words 0KB
VIEWER 0 cells 0 words 0KB
VIEWSURFACE 0 cells 0 words 0KB
TEKTRO-VIEWSURFACE 0 cells 0 words 0KB
XOBJECT 0 cells 0 words 0KB
GCONTEXT 7 cells 42 words 0KB
XDRAWABLE 0 cells 0 words 0KB
XPIXMAP 5 cells 45 words 0KB
XWINDOW 2 cells 30 words 0KB
PANEL 0 cells 0 words 0KB
MENU-PANEL 0 cells 0 words 0KB
MENUBAR-PANEL 0 cells 0 words 0KB
PIXMAP-SCROLLER 0 cells 0 words 0KB
EUSTOP-WIN 0 cells 0 words 0KB
FILEDIALOG 0 cells 0 words 0KB
FILEPANEL 0 cells 0 words 0KB
TEXTVIEWPANEL 0 cells 0 words 0KB
CONFIRMPANEL 0 cells 0 words 0KB
COLORPICKERPANEL 0 cells 0 words 0KB
OBJECTBROWSER 0 cells 0 words 0KB
TABBED-PANEL 0 cells 0 words 0KB
IRTVIEWER 0 cells 0 words 0KB
CANVAS 0 cells 0 words 0KB
GRAPH-CANVAS 0 cells 0 words 0KB
PANEL-ITEM 0 cells 0 words 0KB
BUTTON-ITEM 0 cells 0 words 0KB
MENU-BUTTON-ITEM 0 cells 0 words 0KB
BITMAP-BUTTON-ITEM 0 cells 0 words 0KB
PANEL-TAB-BUTTON-ITEM 0 cells 0 words 0KB
TEXT-ITEM 0 cells 0 words 0KB
SLIDER-ITEM 0 cells 0 words 0KB
CHOICE-ITEM 0 cells 0 words 0KB
JOYSTICK-ITEM 0 cells 0 words 0KB
XSCROLL-BAR 0 cells 0 words 0KB
XHORIZONTAL-SCROLL-BAR 0 cells 0 words 0KB
CHARACTERWINDOW 0 cells 0 words 0KB
TEXTWINDOW 0 cells 0 words 0KB
BUFFERTEXTWINDOW 0 cells 0 words 0KB
SCROLLTEXTWINDOW 0 cells 0 words 0KB
TEXTEDIT 0 cells 0 words 0KB
EUSTOP-HISTORY-WINDOW 0 cells 0 words 0KB
GLVIEWSURFACE 0 cells 0 words 0KB
DDA 0 cells 0 words 0KB
LINE-DDA 0 cells 0 words 0KB
ELLIPSE-DDA 0 cells 0 words 0KB
CIRCLE-DDA 0 cells 0 words 0KB
COLORMAP 1 cells 6 words 0KB
COLORMATERIAL 913 cells 8217 words 64KB
LIGHTSOURCE 0 cells 0 words 0KB
NODE 0 cells 0 words 0KB
ARCED-NODE 0 cells 0 words 0KB
ARC 0 cells 0 words 0KB
COSTED-ARC 0 cells 0 words 0KB
DIRECTED-GRAPH 0 cells 0 words 0KB
COSTED-GRAPH 0 cells 0 words 0KB
GRAPH 0 cells 0 words 0KB
SOLVER-NODE 0 cells 0 words 0KB
SOLVER 0 cells 0 words 0KB
GRAPH-SEARCH-SOLVER 0 cells 0 words 0KB
BREADTH-FIRST-GRAPH-SEARCH-SOLVER 0 cells 0 words 0KB
DEPTH-FIRST-GRAPH-SEARCH-SOLVER 0 cells 0 words 0KB
BEST-FIRST-GRAPH-SEARCH-SOLVER 0 cells 0 words 0KB
A*-GRAPH-SEARCH-SOLVER 0 cells 0 words 0KB
INTERVAL-TIME 0 cells 0 words 0KB
CALENDAR-TIME 0 cells 0 words 0KB
PGSQL 0 cells 0 words 0KB
JOINT 0 cells 0 words 0KB
ROTATIONAL-JOINT 0 cells 0 words 0KB
LINEAR-JOINT 0 cells 0 words 0KB
WHEEL-JOINT 0 cells 0 words 0KB
OMNIWHEEL-JOINT 0 cells 0 words 0KB
SPHERE-JOINT 0 cells 0 words 0KB
BVH-SPHERE-JOINT 0 cells 0 words 0KB
6DOF-JOINT 0 cells 0 words 0KB
BVH-6DOF-JOINT 0 cells 0 words 0KB
RICCATI-EQUATION 0 cells 0 words 0KB
PREVIEW-CONTROL 0 cells 0 words 0KB
EXTENDED-PREVIEW-CONTROL 0 cells 0 words 0KB
PREVIEW-DYNAMICS-FILTER 0 cells 0 words 0KB
GAIT-GENERATOR 0 cells 0 words 0KB
MOTION-CAPTURE-DATA 0 cells 0 words 0KB
OBJECT 0 cells 0 words 0KB
TIME 1 cells 3 words 0KB
COLORRGBA 0 cells 0 words 0KB
FLOAT64MULTIARRAY 0 cells 0 words 0KB
BYTEMULTIARRAY 0 cells 0 words 0KB
INT32 0 cells 0 words 0KB
BYTE 0 cells 0 words 0KB
UINT64 0 cells 0 words 0KB
INT16 0 cells 0 words 0KB
INT64 0 cells 0 words 0KB
UINT8 0 cells 0 words 0KB
INT64MULTIARRAY 0 cells 0 words 0KB
TIME 0 cells 0 words 0KB
FLOAT32 0 cells 0 words 0KB
INT32MULTIARRAY 0 cells 0 words 0KB
UINT32 0 cells 0 words 0KB
INT8 0 cells 0 words 0KB
UINT16MULTIARRAY 0 cells 0 words 0KB
MULTIARRAYLAYOUT 0 cells 0 words 0KB
UINT8MULTIARRAY 0 cells 0 words 0KB
UINT32MULTIARRAY 0 cells 0 words 0KB
FLOAT32MULTIARRAY 0 cells 0 words 0KB
MULTIARRAYDIMENSION 0 cells 0 words 0KB
BOOL 0 cells 0 words 0KB
HEADER 0 cells 0 words 0KB
INT16MULTIARRAY 0 cells 0 words 0KB
DURATION 0 cells 0 words 0KB
CHAR 0 cells 0 words 0KB
EMPTY 0 cells 0 words 0KB
FLOAT64 0 cells 0 words 0KB
STRING 0 cells 0 words 0KB
UINT64MULTIARRAY 0 cells 0 words 0KB
INT8MULTIARRAY 0 cells 0 words 0KB
UINT16 0 cells 0 words 0KB
WRENCH 0 cells 0 words 0KB
POSE 0 cells 0 words 0KB
POSE2D 0 cells 0 words 0KB
POINTSTAMPED 0 cells 0 words 0KB
POSEARRAY 0 cells 0 words 0KB
POINT32 0 cells 0 words 0KB
POSEWITHCOVARIANCESTAMPED 0 cells 0 words 0KB
POLYGONSTAMPED 0 cells 0 words 0KB
TWISTSTAMPED 0 cells 0 words 0KB
QUATERNIONSTAMPED 0 cells 0 words 0KB
TRANSFORMSTAMPED 0 cells 0 words 0KB
QUATERNION 0 cells 0 words 0KB
TWIST 0 cells 0 words 0KB
POLYGON 0 cells 0 words 0KB
VECTOR3 0 cells 0 words 0KB
TWISTWITHCOVARIANCE 0 cells 0 words 0KB
POINT 0 cells 0 words 0KB
VECTOR3STAMPED 0 cells 0 words 0KB
TRANSFORM 0 cells 0 words 0KB
WRENCHSTAMPED 0 cells 0 words 0KB
POSEWITHCOVARIANCE 0 cells 0 words 0KB
TWISTWITHCOVARIANCESTAMPED 0 cells 0 words 0KB
POSESTAMPED 0 cells 0 words 0KB
TRANSFORMER 0 cells 0 words 0KB
TRANSFORM-LISTENER 1 cells 3 words 0KB
TRANSFORM-BROADCASTER 0 cells 0 words 0KB
GOALSTATUSARRAY 0 cells 0 words 0KB
GOALSTATUS 0 cells 0 words 0KB
GOALID 0 cells 0 words 0KB
SIMPLE-ACTION-CLIENT 0 cells 0 words 0KB
SIMPLE-ACTION-SERVER 0 cells 0 words 0KB
LASERSCAN 0 cells 0 words 0KB
JOYFEEDBACK 0 cells 0 words 0KB
RANGE 0 cells 0 words 0KB
CAMERAINFO 0 cells 0 words 0KB
NAVSATFIX 0 cells 0 words 0KB
JOINTSTATE 0 cells 0 words 0KB
IMU 0 cells 0 words 0KB
POINTFIELD 0 cells 0 words 0KB
CHANNELFLOAT32 0 cells 0 words 0KB
REGIONOFINTEREST 0 cells 0 words 0KB
NAVSATSTATUS 0 cells 0 words 0KB
JOYFEEDBACKARRAY 0 cells 0 words 0KB
JOY 0 cells 0 words 0KB
TIMEREFERENCE 0 cells 0 words 0KB
COMPRESSEDIMAGE 0 cells 0 words 0KB
IMAGE 0 cells 0 words 0KB
POINTCLOUD2 0 cells 0 words 0KB
POINTCLOUD 0 cells 0 words 0KB
MENUENTRY 0 cells 0 words 0KB
INTERACTIVEMARKERFEEDBACK 0 cells 0 words 0KB
INTERACTIVEMARKER 0 cells 0 words 0KB
INTERACTIVEMARKERINIT 0 cells 0 words 0KB
MARKERARRAY 0 cells 0 words 0KB
MARKER 0 cells 0 words 0KB
INTERACTIVEMARKERPOSE 0 cells 0 words 0KB
IMAGEMARKER 0 cells 0 words 0KB
INTERACTIVEMARKERUPDATE 0 cells 0 words 0KB
INTERACTIVEMARKERCONTROL 0 cells 0 words 0KB
EMPTYREQUEST 0 cells 0 words 0KB
EMPTYRESPONSE 0 cells 0 words 0KB
EMPTY 0 cells 0 words 0KB
ACTIONLIB-COMM-STATE 0 cells 0 words 0KB
COMPILED-CODE 3725 cells 22350 words 174KB
FOREIGN-CODE 840 cells 7560 words 59KB
CLOSURE 1 cells 9 words 0KB
LOAD-MODULE 86 cells 774 words 6KB
LABEL-REFERENCE 64 cells 384 words 3KB
VECTOR 1466 cells 95262 words 744KB
FLOAT-VECTOR 3845 cells 23109 words 180KB
INTEGER-VECTOR 8 cells 60 words 0KB
STRING 18671 cells 130347 words 1018KB
SOCKET-ADDRESS 0 cells 0 words 0KB
CSTRUCT 0 cells 0 words 0KB
CARRAY 0 cells 0 words 0KB
C-LONG 0 cells 0 words 0KB
C-INT 0 cells 0 words 0KB
GCVALUES 1 cells 24 words 0KB
XCOLOR 0 cells 0 words 0KB
SETWINDOWATTRIBUTES 1 cells 24 words 0KB
WINDOWATTRIBUTES 1 cells 24 words 0KB
XEVENT 2 cells 78 words 0KB
BIT-VECTOR 2 cells 6 words 0KB
FOREIGN-STRING 1 cells 3 words 0KB
EXTENDED-NUMBER 0 cells 0 words 0KB
RATIO 0 cells 0 words 0KB
COMPLEX 0 cells 0 words 0KB
BIGNUM 1 cells 3 words 0KB
SOCKET-PORT 0 cells 0 words 0KB
PATHNAME 1 cells 9 words 0KB
URL-PATHNAME 0 cells 0 words 0KB
HASH-TABLE 1 cells 15 words 0KB
TRANSLATOR 1 cells 6 words 0KB
IDENTIFIER 0 cells 0 words 0KB
IDENTIFIER-TABLE 1 cells 6 words 0KB
STACK-FRAME 0 cells 0 words 0KB
COMPILER 1 cells 15 words 0KB
BOUNDING-BOX 0 cells 0 words 0KB
CONSTRAINED-POINT 0 cells 0 words 0KB
CONSTRAINT-RELATION 0 cells 0 words 0KB
EDGE-IMAGE 0 cells 0 words 0KB
FACE-IMAGE 0 cells 0 words 0KB
STEREO-VIEWING 0 cells 0 words 0KB
HELP-ITEM 0 cells 0 words 0KB
LINECOLOR 0 cells 0 words 0KB
MTIMER 0 cells 0 words 0KB
holes 143517 cells 304882107 words 2381891KB
nilgcの話については、 jmanual.pdf 79ページ、11.1メモリ管理 に書いてあります。 空いているメモリが少なくなったらGCして、空きが少ないとeusの使用メモリを拡張します。 それらの、スレッショルドは変数で指定することができます。
また、一度大きくした使用メモリを返却することはしないので、eus内でガーベージコレクション されていても、プロセスとしてのメモリ使用量は減りません。
GCの説明とは関係ないですが、この問題はなんとなく根深い問題な気がします。 メッセージを出すのをやめるとメモリ使用量は増えないように見えます。 32bit環境でこの問題が起こるか確認できた人はいますでしょうか？
k-okada
commented
10 years ago roseus/test/test-tf.lのテストプログラムでデバッグメッセージをだしたり，メモリのリーク状態を確認するようにしました． で，:lookup-transformを段階をおって幾つか調べてみると，
(ros::eustf-lookup-transform (l . ros::cobject) "MANDALAY" "TOKYO" (send (ros::time) :sec-nsec)))とするだけだと大丈夫なんだけど，
(ros::eustf-lookup-transform (l . ros::cobject) "MANDALAY" "JUPITER" (se\
nd (ros::time) :sec-nsec))
(setq ret #f(0 0 0 1 0 0 0))
(make-cascoords :pos (float-vector
(* 1000.0 (elt ret 0))
(* 1000.0 (elt ret 1))
(* 1000.0 (elt ret 2)))
:rot
(user::quaternion2matrix
(float-vector (elt ret 3)
(elt ret 4)
(elt ret 5)
(elt ret 6)))
:name "MANDALAY"))
だとメモリーが解放されていないように見える． とすると，と思ってeuslisp/test/coords.lを作ってmake-coordsでメモリが大丈夫か見ているんだけど，
(setq i-max 1000000) ;; fail
(setq i-max 200000)
(deftest test-makecoords-rpy
(dotimes (j 20)
(dotimes (i i-max)
(setq ret #f(0 0 0))
(make-cascoords :pos (float-vector 0 0 0)
:rpy (float-vector 0 0 0)))
;;
(setq vmrss (elt (unix::getrusage 0) 2))
(format *error-output* "~A gc:~A, vmrss:~A~%" j (sys::gc) vmrss)
(assert (< vmrss 300000) "make-coords pos/rpy")))
という感じでi-maxが1000000だと確かに解放されないメモリがありそうな気がするんだけど，本当かな？ そんなところにバグがあるだろうか？
という状況です．
k-okada
commented
10 years ago また、一度大きくした使用メモリを返却することはしないので、eus内でガーベージコレクション されていても、プロセスとしてのメモリ使用量は減りません。
なるほど、ということはGCにより空きがあるにもかかわらずメモリが足りないと勘違いして メモリを確保してしまっているということですね。
32bitのVMでは、上記のスクリプトを実行後もRSS 20mとなり大丈夫そうです。 gcの頻度も落ちませんでした。
k-okada
commented
10 years ago ほとんどの問題点は簡単な事柄が原因なので，小難しいことを言い出したら怪しいというのが僕の持論ですが，copy-objectが怪しんじゃないかという結論になりつつあります．eus本体の問題なので https://sourceforge.net/p/jskeus/tickets/28/ にチケットを切りました．フォローしてもらえると嬉しいです．
aginika
commented
9 years ago please close
k-okada
commented
9 years ago 上のsourceforgeのissueのgithub版はどこでしょうか？そこのリンクを貼ってください．そしたらクローズしましょう．
aginika
commented
9 years ago k-okada
commented
9 years ago
This post was originally posted at http://sourceforge.net/p/jsk-ros-pkg/tickets/158
操縦にroseusを使用していますが、メモリの使用量が時間とともに増えていきます。
ROSEUS_SERVICE_CALLの中で、 ServiceClient* srv = new ServiceClient(client); としていますが、これをdeleteするようにすると、いくらかマシになるという報告があります。