Poor memory performance due to memory leaks

[pavelhiq]

With just normal use of a map (moving around, zooming in and out, updating pins etc) I observe that the amount of leaked memory grows up pretty quickly to some really scary numbers. And the leaks tool illustrates this like so:

leaks Report Version: 4.0, multi-line stacks
Process 89239: 610467 nodes malloced for 143704 KB
Process 89239: 10081 leaks for 37312640 total leaked bytes.

STACK OF 247 INSTANCES OF 'ROOT LEAK: <malloc in _yandex_impl___ZN5boost10coroutines30basic_standard_stack_allocatorINS0_12stack_traitsEE8allocateERNS0_13stack_contextEm>':
9   libsystem_pthread.dylib               0x1dc9c4948 thread_start + 8
8   libsystem_pthread.dylib               0x1dc9c6348 _pthread_start + 116
7   MyApp                                 0x106ac0770 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, yandex::maps::runtime::ThreadPriority, yandex::maps::runtime::internal::ThreadPool::ThreadPool(unsigned int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::function<void (yandex::maps::runtime::Event*)>, yandex::maps::runtime::ThreadPriority)::$_0&&), std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, yandex::maps::runtime::ThreadPriority, yandex::maps::runtime::internal::ThreadPool::ThreadPool(unsigned int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::function<void (yandex::maps::runtime::Event*)>, yandex::maps::runtime::ThreadPriority)::$_0> >(void*) + 68
6   MyApp                                 0x106abef7c void yandex::maps::runtime::internal::threadRunner<yandex::maps::runtime::internal::ThreadPool::ThreadPool(unsigned int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::function<void (yandex::maps::runtime::Event*)>, yandex::maps::runtime::ThreadPriority)::$_0>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, yandex::maps::runtime::ThreadPriority, yandex::maps::runtime::internal::ThreadPool::ThreadPool(unsigned int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::function<void (yandex::maps::runtime::Event*)>, yandex::maps::runtime::ThreadPriority)::$_0&&) + 104
5   MyApp                                 0x106ad39cc yandex::maps::runtime::async::internal::coro::(anonymous namespace)::TaskHolder::operator()() + 48
4   MyApp                                 0x106ad41b4 yandex::maps::runtime::async::internal::coro::run(yandex::maps::runtime::async::internal::coro::SchedulableTask, bool) + 132
3   MyApp                                 0x106ad4378 yandex::maps::runtime::async::internal::coro::Task::run(unsigned int, bool) + 172
2   MyApp                                 0x106ad53d8 boost::coroutines::push_coroutine<void>::push_coroutine<std::__1::__bind<void (yandex::maps::runtime::async::internal::coro::Task::*)(boost::coroutines::pull_coroutine<void>&), yandex::maps::runtime::async::internal::coro::Task*, std::__1::placeholders::__ph<1> const&> >(std::__1::__bind<void (yandex::maps::runtime::async::internal::coro::Task::*)(boost::coroutines::pull_coroutine<void>&), yandex::maps::runtime::async::internal::coro::Task*, std::__1::placeholders::__ph<1> const&>&&, boost::coroutines::attributes const&) + 56
1   MyApp                                 0x106ad5438 _yandex_impl___ZN5boost10coroutines30basic_standard_stack_allocatorINS0_12stack_traitsEE8allocateERNS0_13stack_contextEm + 28
0   libsystem_malloc.dylib                0x19286befc _malloc_zone_malloc + 148 
====
    3302 (35.3M) << TOTAL >>

So yandex maps runtime internals seem to be responsible for 99% of the leaked memory for the whole process. Obviously this contributes a lot to the app's memory footprint and means more app terminations, not to mention poor experience for our end users.

[YandexMapKit]

Please specify the environment: device model and operating system version, MapKit version.
Also, a minimal code example for analyzing leaks will be useful to us. You can upload it as a project on GitHub, attach to the correspondence in the archive or upload to the cloud storage and specify the link.

[pavelhiq]

The device was an iPhone 7 running iOS 15.7.3. And the MapKit version used is 4.4.0-full.
I will try to come up with a code example. However, Im not the first highlighting the issue (even though originating from some other repo) - I believe it should be pretty easy to reproduce it on your side.

[YandexMapKit]

We failed to reproduce the situation with leaks. Please provide a minimal code example for further analysis.

[pavelhiq]

Hi, I have tried it with the reference demo project recently. It did leak when the Malloc Stack Logging option was enabled. I haven't heard of any possible side effects like this for just capturing backtraces. @YandexMapKit would you please confirm the behaviour and elaborate on the possible why?

[YandexMapKit]

We checked the demo application for memory leaks. We noticed some minor leaks. But we did not succeed in achieving values ​​that were anywhere close to those indicated in the original question.

If you can describe in detail the environment in which major memory leaks occur, so that it can be stably reproduced, we are ready to review the situation again. You can extend the example with some automatic actions, after which a leak occurs.