Fixed potential memory issue and message duplication with large strings

[snakefoot]

StringBuilderPool - Allow FastPool-object to have larger capacity, but missing reset

Serious bug introduced with #2934

If writing very large log-message, then NLog will never forget it.

Will try later to make a unit-test for this special logic about releasing StringBuilders that have become too big.

[codecov-io]

Codecov Report

Merging #3345 into dev will increase coverage by <1%.
The diff coverage is 100%.

@@          Coverage Diff           @@
##             dev   #3345    +/-   ##
======================================
+ Coverage     80%     80%   +<1%     
======================================
  Files        356     356            
  Lines      28207   28205     -2     
  Branches    3750    3750            
======================================
+ Hits       22580   22607    +27     
+ Misses      4541    4515    -26     
+ Partials    1086    1083     -3

[snakefoot]

@304NotModified The bug will be triggered by logging a very large log-message. After having logged this message, then NLog will continuously log the same very large log-message over and over.

So if logging a very large message then it will not be a "potential" issue, but a very certain issue :)

[304NotModified]

Is it a memory issue, or are the messages duplicated?

[snakefoot]

Is it a memory issue, or are the messages duplicated?

Both. After the bug has been triggered. Then it will concat to the same buffer. Only when it finally becomes extremely large then it will reset the buffer properly.

[304NotModified]

Could we please add an unit test for this? I'm curious how big the message should be as none of the tests fails.

[snakefoot]

Like I said, then I have been trying to make an unit-test of the StringBuilderPool ability to release too large StringBuilders.

But it requires several Threads and physical cores to properly see that it is failing. And when running in release-mode then it is almost impossible.

One could write a unit-test for the specific bug, but it would be very dependent on the magic optimization-values in the StringBuilderPool. And when changing the values then the unit-test will not be testing anything. So not that keen on doing that.

[304NotModified]

Like I said, then I have been trying to make an unit-test of the StringBuilderPool ability to release too large StringBuilders.

Oops, missed that.

Busy, but will try to create a release ASAP