Hi All,<br><br>I am trying to locate which part of our application that causes a memory spike. Considering that our application is composed of about two hundred elements which are scattered over 70 threads, I use Massif, one of Valgrind tools to check heap memory profile during the execution of our application. I list the detailed information of snapshot 48 of Massif output. As you can see that starting "this" thread consumes most of the memory. Also I found that this thread is not such thread that is created by "queue" element, because I can see that "queue" thread are created after the memory spike. It seems like it is a main thread that handles preliminary things. Can anyone give me some explanation about it. Any help is appreciated. <br>
<br>Thanks!<br><br> GB<br>1.079^ #<br> | :@:::@#<br> | :@:::::@:::@:::@#<br>
| ::::::::::::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br>
| :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br>
| :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br>
| :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br>
| :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br> | :::::::::::: :: ::@:::::@:::@:::@#<br>
| :::::::::::: :: ::@:::::@:::@:::@#<br> | ::@:::::::::::::::::::::@@@@::::::::::::::::::::: :: ::@:::::@:::@:::@#<br> 0 +----------------------------------------------------------------------->Gi<br>
0 619.3<br><br>Number of snapshots: 52<br> Detailed snapshots: [3, 9, 32, 38, 43, 47, 48 (peak), 51]<br><br> <br>--------------------------------------------------------------------------------<br>
n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B)<br>--------------------------------------------------------------------------------<br> 48 661,339,638,719 1,158,568,168 1,153,638,753 4,929,415 0<br>
<br> 99.57% (1,153,638,753B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.<br>->71.34% (826,503,872B) 0x3054430468: gst_buffer_try_new_and_alloc (in /usr/lib64/libgstreamer-0.10.so.0.29.0)<br>| ->71.34% (826,503,872B) 0x30544593E4: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)<br>
| ->67.01% (776,396,992B) 0x3054C2E34A: ??? (in /usr/lib64/libgstbase-0.10.so.0.29.0)<br>| | ->67.01% (776,396,992B) 0x3054C2EA6A: ??? (in /usr/lib64/libgstbase-0.10.so.0.29.0)<br>| | ->67.01% (776,396,992B) 0x305445DEC8: gst_pad_push (in /usr/lib64/libgstreamer-0.10.so.0.29.0)<br>
| | | ->67.01% (776,396,800B) 0x2851A728: ??? (in /usr/lib64/gstreamer-0.10/libgstcoreelements.so)<br>| | | | ->67.01% (776,396,800B) 0x3054484362: ??? (in /usr/lib64/libgstreamer-0.10.so.0.29.0)<br>| | | | ->67.01% (776,396,800B) 0x303526C746: ??? (in /lib64/libglib-2.0.so.0.3000.2)<br>
| | | | ->67.01% (776,396,800B) 0x303526A224: ??? (in /lib64/libglib-2.0.so.0.3000.2)<br>| | | | ->67.01% (776,396,800B) 0x3033607D8E: start_thread (in /lib64/<a href="http://libpthread-2.14.90.so">libpthread-2.14.90.so</a>)<br>
| | | | <br>| | | ->00.00% (192B) in 1+ places, all below ms_print's threshold (01.00%)<br>| | | <br>| | ->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)<br>| | <br clear="all">
<br>-- <br>Qi Chu, Ph.D student<br>Australian International Gravitational Research Centre<br>School of physics<br>The University of Western Australia<br>M013, 35 Stirling Hwy<br>Crawley, WA 6009<br>Australia<br>Email: <a href="mailto:chicsheep@gmail.com" target="_blank">chicsheep@gmail.com</a><br>
<br><br>