Memory leak in wxSearchCtrl with autocomplete (Issue #24555)
PB
(Based on a report on wxForum).
Bug description
When calling wxSearchCtrl::AutoComplete() on Windows and typing at least one character into it (regardless of it being matched), MSVS reports a memory leak after the program exits:
Detected memory leaks!
Dumping objects ->
{297524} normal block at 0x000002827A7D3090, 1544 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{297523} normal block at 0x000002827C402980, 48 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 CD CD CD CD CD CD CD
Object dump complete.
The the leak (size/count) does not change with number of wxSearchCtrls used in the program.
The memory allocation number varies with each run so I could not easily pinpoint the leak location.
The leak is not present in the GIT master but I did not do GIT bisect (have trouble doing that across versions due to change in Scintilla modules).
Patch or snippet allowing to reproduce the problem:
diff --git a/samples/widgets/searchctrl.cpp b/samples/widgets/searchctrl.cpp index 1e8d3683d3..94e81951c9 100644 --- a/samples/widgets/searchctrl.cpp +++ b/samples/widgets/searchctrl.cpp @@ -179,6 +179,8 @@ void SearchCtrlWidgetsPage::CreateControl() m_srchCtrl = new wxSearchCtrl(this, -1, wxEmptyString, wxDefaultPosition, FromDIP(wxSize(150, -1)), style); + + m_srchCtrl->AutoComplete(wxArrayString{"abc"}); } void SearchCtrlWidgetsPage::RecreateWidget()
To Reproduce:
- Run the patched widgets sample from MSVS.
- Go to wxSearchCtrl page.
- Type at last one letter into the search control and exit the sample.
- Observe the memory leak report.
Platform and version information
- wxWidgets version: 3.2.5 (issue not present in the GIT master)
- wxWidgets port: wxMSW
- OS: Windows 10
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I wonder if it's wxTextAutoCompleteData being leaked...
The strange thing is that there doesn't seem to have been any changes in this area since 3.2, so I don't see how could this be fixed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
I can't repro in 3.2.0 and 3.2.2.1 either, it starts manifesting in 3.2.3.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
If you could please bisect between 3.2.2 and 3.2.3 (there should be no problems due to submodule changes in this range), it would be great, TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
This commit is the culprit: d666d1e
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Sorry, I don't understand: this commit is on master, do you mean that it fixed the leak? This still doesn't explain why it didn't exist in 3.2.0...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
Sorry, I posted the master version of the commit, it should have been: e19984e
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Thanks!
This probably means that it's just a false positive, i.e. I believe that the callback cleanup function is called to free this memory — but it happens after the MSVC CRT makes its report. To be totally sure, you could try running the sample under the debugger and put a breakpoint on wxThreadSpecificInfoTLS::DeleteThreadSpecificInfo(): it should be triggered for the thread created by Windows internally when the program exit but you should already see the leak reported in the debug output window by the time this happens.
Even if my hypothesis is correct, it's still not nice to get these leak reports, but I don't know what to do about them. Perhaps there is some way to tell the debug CRT to ignore this allocation?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
PB
The breakpoint wxThreadSpecificInfoTLS::DeleteThreadSpecificInfo() is hit once (for the main thread), the memory leak report is shown in the MSVS debug output only after that.
However, the report looks like this
The thread 14792 has exited with code 0 (0x0).
The thread 13136 has exited with code 0 (0x0).
The thread 4828 has exited with code 0 (0x0).
The thread 13248 has exited with code 0 (0x0).
The thread 11168 has exited with code 0 (0x0).
Detected memory leaks!
Dumping objects ->
<snipped>
Object dump complete.
The program '[16348] widgets.exe' has exited with code 0 (0x0).
The main thread is not among the exited threads listed before the report. Perhaps the main thread is never listed and instead the process exit (with process id instead thread id) is used, shown only after the memory leak report.
Ad for preventing false positives, it seems there is _IGNORE_BLOCK but I have no idea how to properly use it or even if it should be used here...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.