actix-router 0.2.6 leaks memory

[glademiller]

After upgrading to actix-router 0.2.6 from 0.2.5 I started to see regular memory increases. After running valgrind I found a lot of the following.

==20484== 8,192 bytes in 8 blocks are definitely lost in loss record 119 of 147
==20484==    at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20484==    by 0x61EF4E: regex::dfa::Cache::new (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x61EE66: regex::exec::ProgramCacheInner::new (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x6232E9: regex::re_unicode::Regex::captures (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x43E3A5: <actix_web::app_service::AppRouting as actix_service::Service>::call (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x360946: <data_science_adaptor::middleware::auth::AuthMiddleware<S> as actix_service::Service>::call (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x2CA73F: <actix_http::cloneable::CloneableService<T> as actix_service::Service>::call (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x1CC981: actix_http::h1::dispatcher::InnerDispatcher<T,S,B,X,U>::handle_request (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x1CA512: actix_http::h1::dispatcher::InnerDispatcher<T,S,B,X,U>::poll_request (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x1D7FAB: <actix_http::h1::dispatcher::Dispatcher<T,S,B,X,U> as core::future::future::Future>::poll (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x1C93F9: <actix_service::and_then::AndThenServiceResponse<A,B> as core::future::future::Future>::poll (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x30EB17: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484== 
==20484== 8,448 (256 direct, 8,192 indirect) bytes in 8 blocks are definitely lost in loss record 120 of 147
==20484==    at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20484==    by 0x1AA0AF: <futures_util::future::try_future::MapOk<Fut,F> as core::future::future::Future>::poll (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x433239: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x431E73: tokio::runtime::task::raw::poll (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x40BD27: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x407C7E: actix_rt::runtime::Runtime::block_on (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x40632F: std::sys_common::backtrace::__rust_begin_short_backtrace (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x405D07: core::ops::function::FnOnce::call_once{{vtable-shim}} (in /home/glade/code/data-science-adaptor/target/release/data-science-adaptor)
==20484==    by 0x796879: call_once<(),FnOnce<()>,alloc::alloc::Global> (boxed.rs:1307)
==20484==    by 0x796879: call_once<(),alloc::boxed::Box<FnOnce<()>, alloc::alloc::Global>,alloc::alloc::Global> (boxed.rs:1307)
==20484==    by 0x796879: std::sys::unix::thread::Thread::new::thread_start (thread.rs:71)
==20484==    by 0x5BDA6DA: start_thread (pthread_create.c:463)
==20484==    by 0x64B571E: clone (clone.S:95)

After forcing my project to use version 0.2.5 valgrind finds no leaks.

[robjtede]

If you create a minimal reproduction using just router that'd be great.

[glademiller]

After looking at what was going I don't think the problem lies with actix-router but with thread_local via the Regex crate. This PR Amanieu/thread_local-rs#30 that was just merged and a new version of thread_local was release. Looks like it solved my problem.