Okay, I can now confirm that this is exactly what is happening. The unique_ptr destructor is being called after the ROOT environment has already freed the memory address pointed by m_style. Here is the AddressSanitizer output:
==2410049==ERROR: AddressSanitizer: heap-use-after-free on address 0x51b000003f80 at pc 0x7d228dd7eb03 bp 0x7ffde90800a0 sp 0x7ffde9080098
READ of size 8 at 0x51b000003f80 thread T0
#0 0x7d228dd7eb02 in std::default_delete<TStyle>::operator()(TStyle*) const /home/gabrielribcesario/miniconda3/envs/nnbar/lib/gcc/x86_64-conda-linux-gnu/14.3.0/include/c++/bits/unique_ptr.h:93
#1 0x7d228dd7eb02 in std::unique_ptr<TStyle, std::default_delete<TStyle> >::~unique_ptr() /home/gabrielribcesario/miniconda3/envs/nnbar/lib/gcc/x86_64-conda-linux-gnu/14.3.0/include/c++/bits/unique_ptr.h:399
#2 0x7d228cc45a55 in __cxa_finalize stdlib/cxa_finalize.c:83
#3 0x7d228d91b0c1 (/home/gabrielribcesario/garfieldpp/install/lib/libGarfield.so.0.3+0x11b0c1)
0x51b000003f80 is located 0 bytes inside of 1552-byte region [0x51b000003f80,0x51b000004590)
freed by thread T0 here:
#0 0x7d22908b2f87 in operator delete(void*) ../../../../libsanitizer/asan/asan_new_delete.cpp:152
#1 0x7d228d484540 in TList::Delete(char const*) (/home/gabrielribcesario/miniconda3/envs/nnbar/lib/libCore.so.6.34+0x284540)
previously allocated by thread T0 here:
#0 0x7d22908b2814 in operator new(unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cpp:95
#1 0x7d228d423ef9 in TStorage::ObjectAlloc(unsigned long) (/home/gabrielribcesario/miniconda3/envs/nnbar/lib/libCore.so.6.34+0x223ef9)
SUMMARY: AddressSanitizer: heap-use-after-free /home/gabrielribcesario/miniconda3/envs/nnbar/lib/gcc/x86_64-conda-linux-gnu/14.3.0/include/c++/bits/unique_ptr.h:93 in std::default_delete<TStyle>