[boost][stacktrace] stacktrace keep eating memory

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[boost][stacktrace] stacktrace keep eating memory

Boost - Users mailing list

 

I am using stacktrace on Windows. I found stacktrace keep eating my memory. A simple test program:

 

void foo() {

  auto st = boost::stacktrace::stacktrace{};

  auto line = st.begin()->source_line();

  std::cout << line << std::endl;

}

void main() {

  for (int i = 0; i < 0xFFFF; i++) {

    foo();

  }

}

 

Based on MSVC memory profiling tool, memory usage keep growth:

 

And frame allocator is taking heap:

 

 

Anyone knows why it happens?

 

Br,

Hao.

 

 

Platform: Windows 7.

Compiler: MSVC 2017

Boost version: 1.67

Compile and link: release, static-link, static runtime.


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [boost][stacktrace] stacktrace keep eating memory

Boost - Users mailing list
On Wed, Mar 20, 2019 at 6:05 AM Hao Jiang via Boost-users <[hidden email]> wrote:

I am using stacktrace on Windows. I found stacktrace keep eating my memory. A simple test program:

 

void foo() {

  auto st = boost::stacktrace::stacktrace{};

  auto line = st.begin()->source_line();

  std::cout << line << std::endl;

}

void main() {

  for (int i = 0; i < 0xFFFF; i++) {

    foo();

  }

}


Presumably the source_line() call asks the library to resolve the symbolic stacktrace information, rather than simply capturing it as in the stacktrace constructor.

Am I reading that screenshot correctly that the size of the leak is 24 bytes per symbolic resolution? The image is a little small.

How hard would it be to identify the operation that causes the allocation in question? I'm curious whether it's simply a dropped pointer in the stacktrace library, or something owned by the underlying platform operations.

I suspect you're driving an unusual / unanticipated use case. I believe the typical assumption is that although a given process might instantiate stacktrace() a large number of times, it won't perform symbolic resolution more than a few times. I believe the library documentation emphasizes that symbolic stacktrace resolution is potentially high-overhead.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

E4C1F975B5B74C4CAD4D9391A0774CED.png (9K) Download Attachment
AE8C0B8E482C4AAC9339566E1EA6CAD8.png (39K) Download Attachment