Fixed potential memory issue and message duplication with large strings#3345
Conversation
…t remember to reset
Codecov Report
@@ 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 |
|
@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 :) |
|
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. |
|
Could we please add an unit test for this? I'm curious how big the message should be as none of the tests fails. |
|
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. |
Oops, missed that. Busy, but will try to create a release ASAP |
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.