Virtual storage grows for a constantly running application

Before asking your question, let me explain my environment:

• I have a C / C ++ application that runs continuously (infinite loop) inside an embedded Linux device.
• The application records some data from the system and saves it in text files on the SD card (1 file per day).
• Writing occurs on a specific trigger found on systems (every 5 minutes, for example), and each trigger inserts a new line into text files.
• Typical data types used in the application are (o/i)stream
  
  , char
  
  arrays char*
  
  , c_str()
  
  function, struct
  
  and struct*
  
  , static string
  
  arrays, #define
  
  , enums
  
  , FILE*
  
  , vector<>
  
  and conventional ( int
  
  , string
  
  etc.). Some of these data types are passed as arguments to functions.
• The application is cross-compiled with the dedicated GCC compiler in Buildroot and BusyBox for the Atmel AT91RM9200QU CPU device.
• The application executes some system commands using popen
  
  , in which the output is read using the receivedFILE*
  
  

Now the application has been running for three days and every day I have seen a 32K byte increase in virtual storage (VSZ from the team top

). The device restarted by mistake, I started the application again and the VSZ value started at the usual value every time I started it again (about 2532 KB).

I have developed another application that monitors the VSZ value for the application and it is scheduled using crontab

for each one to start the monitor. I noticed that at some point throughout the day, 32KB I noticed that 4KB every hour.

So the main question is what will cause the increase in VSZ? Eventually it will reach the limit causing the system to crash, which is my problem because the device has approx. 27 MB of RAM.

Update: Besides the value of VSZ, RSS is also increasing. I ran the app under valgrind --leak-check=full

, and after the first entry, I aborted the app and there were many messages popping up many times!

==28211== 28 bytes in 1 blocks are possibly lost in loss record 15 of 52
==28211==    at 0x4C29670: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28211==    by 0x4EF33D8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.19)
==28211==    by 0x4EF4B00: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib64/libstdc++.so.6.0.19)
==28211==    by 0x4EF4F17: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.19)
==28211==    by 0x403842: __static_initialization_and_destruction_0 (gatewayfunctions.h:28)
*==28211==    by 0x403842: _GLOBAL__sub_I__Z18szBuildUDPTelegramSsii (gatewayfunctions.cpp:396)
==28211==    by 0x41AE7C: __libc_csu_init (elf-init.c:88)
==28211==    by 0x5676A94: (below main) (in /lib64/libc-2.19.so)

      

        
        
        
      

    

The same message *

appears , except that line c appears with a different file name. Another thing I notice line 28 of the file gatewayfunctions.h

is the declaration of a static string array, this array is only used in two files. Any suggestions?