Maybe you could verify your assumption by looking into how your RAM memory is consumed by the parser.
To do that you could have the Linker fill the RAM memory that is not used with a known pattern.
Then you could set some breakpoint in your parser to see how the RAM memory usage increases for each iteration the parser runs?!
If you want to insert a pattern in the RAM-memory using the Linker then try inserting Line 11 - 13 this:
/* User_heap_stack section, used to check that there is enough "RAM" Ram type memory left */
._user_heap_stack :
{
. = ALIGN(8);
PROVIDE ( end = . );
PROVIDE ( _end = . );
. = . + _Min_Heap_Size;
. = . + _Min_Stack_Size;
. = ALIGN(8);
FILL(0xFFFFFFFF);
. = ORIGIN(RAM) + LENGTH(RAM) - 1;
BYTE(0xAA)
} >RAM
The example above is copied from a default MX-generated STM32L475VG linker script, where I just insert line 11 - 13... I imagine you have the same structure.
In this case I set the magic pattern to 0xFFFFFFFF. Should be OK in RAM. But maybe not a good idea in FLASH, since reset state is 0xFFFFFFFF in FLASH.
Adding these commands to the user_heap_stack section means that the pattern is only written when binary is loaded to target memory. If you pull the plug to the device the pattern is gone since it is not written by the startup code from flash to RAM.
Another side-effect is that the build analyzer will now report RAM memory usage ~100%.
Now step through your code and look in the memory browser view to see how RAM is consumed... Do you have a stack/heap collision?
