Memory leak in wxSearchCtrl with autocomplete about wxwidgets HOT 8 OPEN

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.

from wxwidgets.

I can't repro in 3.2.0 and 3.2.2.1 either, it starts manifesting in 3.2.3.

from wxwidgets.

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!

from wxwidgets.

This commit is the culprit: d666d1e

from wxwidgets.

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...

from wxwidgets.

Sorry, I posted the master version of the commit, it should have been: e19984e

from wxwidgets.

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?

from wxwidgets.

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...

from wxwidgets.