C
Chris Vanstone
I have raised this issue on the Visual Studio forum but after 3 months they have just closed it and told me to post on here. Please see original posts and follow up comments here - Visual Studio Issue Report
Issue Report
I have found a critical memory leak in Windows 10 - 1809 update regarding line feed characters in a TextBox. Setting a text value that ends in "\r\n" and then replacing it with a value that ends "\n" results in a 1.2GiB to 2GiB Working Set memory leak which ramps linearly with max CPU for around 30 to 60s depending on the spec of the machine it is running on.
The application attached on the Visual Studio forum post (I can't seem to attach here) highlights the exact failure point with strings that are only a few bytes in length.
Process for replication
- Define a TextBox as MultiLine = true
- Write to the Text property a message with a "\r\n" line feed present (i.e "a\r\n")
- Write over the message with a string ending in "\r" (i.e "a\r")
- Application will freeze and memory will leak
Clearing the TextBox before setting doesn't seem to fix the issue, but cycling the MultiLine property between Write operations does. This can be replicated in the application using the check box options.
This cannot be replicated on any systems that have not been updated to Windows 10 1809.
Wondering if the line feed method in the first Text set ("\r\n") is cached, and any subsequent Text updates that do not use the same pattern cause a search through the rest of the heap looking for the next "\n"?
I also noted that this update brought in support for non-Windows line feeds in Notepad and wondered if this had any overlap?
This was initially uncovered in a much larger application where one small component is MultiLine TextBox as a scrolling log which is reduced by 20% when it gets over 100000 chars. The TextBox.Append (for each new line) never seems to cause an issue, but when I overwrite the entire contents (TextBox.Text = ...) with the top 20% removed, the memory leak situation may or may not start depending upon the final linefeed of the message.
Continue reading...
Issue Report
I have found a critical memory leak in Windows 10 - 1809 update regarding line feed characters in a TextBox. Setting a text value that ends in "\r\n" and then replacing it with a value that ends "\n" results in a 1.2GiB to 2GiB Working Set memory leak which ramps linearly with max CPU for around 30 to 60s depending on the spec of the machine it is running on.
The application attached on the Visual Studio forum post (I can't seem to attach here) highlights the exact failure point with strings that are only a few bytes in length.
Process for replication
- Define a TextBox as MultiLine = true
- Write to the Text property a message with a "\r\n" line feed present (i.e "a\r\n")
- Write over the message with a string ending in "\r" (i.e "a\r")
- Application will freeze and memory will leak
Clearing the TextBox before setting doesn't seem to fix the issue, but cycling the MultiLine property between Write operations does. This can be replicated in the application using the check box options.
This cannot be replicated on any systems that have not been updated to Windows 10 1809.
Wondering if the line feed method in the first Text set ("\r\n") is cached, and any subsequent Text updates that do not use the same pattern cause a search through the rest of the heap looking for the next "\n"?
I also noted that this update brought in support for non-Windows line feeds in Notepad and wondered if this had any overlap?
This was initially uncovered in a much larger application where one small component is MultiLine TextBox as a scrolling log which is reduced by 20% when it gets over 100000 chars. The TextBox.Append (for each new line) never seems to cause an issue, but when I overwrite the entire contents (TextBox.Text = ...) with the top 20% removed, the memory leak situation may or may not start depending upon the final linefeed of the message.
Continue reading...