Memory leaks

[Vort]

Microsoft C Runtime library have feature which allows to track memory leaks.
I enabled it, started simple FreeDOS VM, powered it off and got the list of leaked objects: bochs_leaks.txt.

I doubt that most of these leaks are important.
However, thousands of unimportant leaks may be hiding several important ones.

So it may have sense to lower leak amount to zero.
I understand that leak hunting may be not very fun activity.
But I'm reporting it anyway.

[stlintel]

Can you explain how to read it ?
What does it mean for example:

{31256} normal block at 0x00000000071F6680, 18 bytes long.
 Data: <PIIX3 IRQ routin> 50 49 49 58 33 20 49 52 51 20 72 6F 75 74 69 6E 

[stlintel]

Seems like void bx_devices_c::exit() is never called
Should it be called from bx_devices_c::~bx_devices_c() ?

Can you try do it ?

[Vort]

Can you explain how to read it ?

31256 is index of memory allocation.
18 is how many bytes are leaked.
50 49 49... are first bytes of leaked memory block.
PII... are the same first bytes, but in ASCII.

[Vort]

Seems like void bx_devices_c::exit() is never called

I tested two scenraios in fact.
In "load OS and Power off" scenario, bx_devices_c::exit is called, like that:

>	bochs.exe!bx_devices_c::exit() Line 449	C++
 	bochs.exe!bx_pc_system_c::exit() Line 216	C++
 	bochs.exe!bx_atexit() Line 1453	C++
 	bochs.exe!logfunctions::fatal(int level, const char * prefix, const char * fmt, char * ap, int exit_status) Line 670	C++
 	bochs.exe!logfunctions::fatal1(const char * fmt, ...) Line 644	C++
 	bochs.exe!bx_gui_c::power_handler() Line 438	C++
 	bochs.exe!win32_toolbar_click(int x) Line 2128	C++

In other scenario which I did not described yet, it is not called:
When I do not load any OS, just start Bochs and click Quit.
There are also leaks in such scenario.

[stlintel]

So this log above from which scenario ?
I followed some string which seems like name of io_write_handler from bx_devices
And seems like this handler never freed. It is freed in bx_devices_c::exit() so I assumed it is never called

[Vort]

So this log above from which scenario ?

Log from first message is from "OS load" scenario.

Here is log from "Quit" scenario: bochs_leaks_quit.txt.
There are more leaks without bx_devices_c::exit, but not much.

Can you try do it ?

I'm just getting crash in "Quit" scenario if I do it.

[Vort]

This is how leak check can be enabled by the way:

diff --git a/bochs/main.cc b/bochs/main.cc
index 1c7d30f2d..09f9ea61c 100644
--- a/bochs/main.cc
+++ b/bochs/main.cc
@@ -18,6 +18,8 @@
 //  License along with this library; if not, write to the Free Software
 //  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 
+#include <crtdbg.h>
+
 #include "bochs.h"
 #include "bxversion.h"
 #include "param_names.h"
@@ -523,6 +525,7 @@ int WINAPI WinMain(
 // wxWidgets under win32.
 int CDECL main(int argc, char *argv[])
 {
+  _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
   bx_startup_flags.argc = argc;
   bx_startup_flags.argv = argv;
 #ifdef WIN32 

Next you need to just start and exit program in debug mode (F5) and look at Output:

[stlintel]

I have created PR which supposed to reduce the list significantly
Can you try #149 ?

[Vort]

I have created PR which supposed to reduce the list significantly

~37 times less leaks now.
This is what left: bochs_leaks2.txt bochs_leaks2_quit.txt.
Now 16384000 bytes long stands out better :)

[vruppert]

On Linux I can use the tool valgrind to find memory leaks. If debugger support for the gcc compiler is turned on, it points me to the source code line with 'new', 'malloc' or 'strdup' causing a leak. After a long time I tried it once again yesterday and fixed some leaks in the Voodoo and slirp code.

[Vort]

After a long time I tried it once again yesterday and fixed some leaks in the Voodoo and slirp code.

Good. I did not triggered that code paths yet, so no changes in my leak reports.

If debugger support for the gcc compiler is turned on, it points me to the source code line with 'new', 'malloc' or 'strdup' causing a leak.

Something similar is possible also with MS CRT, but it requires some coding.
For example, to find where 16384000 bytes comes from, this code can be added: Vort@7149295.
And here is the result:

[vruppert]

Currently I have a closer look at the paramtree stuff and try to fix it:

• root_param never deleted
• set_format() and set_long_format() usage with strdup()

[Vort]

Fresh dumps: bochs_leaks3.txt (37 leaks) bochs_leaks3_quit.txt (55 leaks).

[vruppert]

I guess you are using a Bochs build with plugins disabled. With the current code the plugin_cleanup() function does nothing if plugins are disabled, but it should call the plugin entry point with the PLUGIN_FINI argument. The gui plugin / object is very special, since there is no PLUGIN_FINI section to delete the bx_gui object. That's why the framebuffer is never freed. I have to test whether or not the PLUGIN_FINI addition works with all guis I can compile here.

[vruppert]

Please try again with the latest code. It works on Windows with and without plugin support present and should fix memory leaks in the devices and gui code.

[Vort]

Please try again with the latest code.

bochs_leaks4_quit.txt now have 24 leaks.
However OS load + power off scenario became worse: crash happens here:

Bochs/bochs/iodev/display/vga.cc

Line 54 in 890a1be

delete theVga;

>	bochs.exe!libvga_plugin_entry(_plugin_t * plugin, unsigned short type, unsigned char mode) Line 54	C++
 	bochs.exe!plugin_cleanup_np() Line 1227	C++
 	bochs.exe!plugin_cleanup() Line 673	C++
 	bochs.exe!bxmain() Line 357	C++
 	bochs.exe!main(int argc, char * * argv) Line 568	C++
 	bochs.exe!invoke_main() Line 65	C++
 	bochs.exe!__scrt_common_main_seh() Line 253	C++
 	bochs.exe!__scrt_common_main() Line 296	C++
 	bochs.exe!mainCRTStartup() Line 17	C++
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

[Vort]

• terminateEmul() is not called: stInfo.kill equals to 1 here:
  

  Bochs/bochs/gui/win32.cc

  Line 2029 in ae107f2

  if (!stInfo.kill) terminateEmul(EXIT_NORMAL);

• bx_unload_plugins() is not called in "Quit" scenario. In OS load + power off scenario it executes fine.

bochs_leaks8.txt - 1 leak, bochs_leaks8_quit.txt - 7 leaks.

[vruppert]

The devices / plugins issues should be fixed now. I'll investigate the remaining win32.cc issue later.

[Vort]

Ok, I see.

I noticed strange crash, which happens in "Quit" scenario when I run Bochs with Ctrl+F5 instead of just F5.
No crash when I run the same executable directly, with Total Commander.
Do not know why is the difference.

>	bochs.exe!iofunctions::remove_logfn(logfunctions * fn) Line 109	C++
 	bochs.exe!logfunctions::~logfunctions() Line 352	C++
 	bochs.exe!bx_devmodel_c::~bx_devmodel_c() Line 86	C++
 	bochs.exe!bx_pci_device_c::~bx_pci_device_c() Line 158	C++
 	bochs.exe!bx_acpi_ctrl_stub_c::~bx_acpi_ctrl_stub_c()	C++
 	bochs.exe!bx_devices_c::~bx_devices_c() Line 81	C++
 	bochs.exe!`dynamic atexit destructor for 'bx_devices''()	C++
 	bochs.exe!_execute_onexit_table::__l22::<lambda>() Line 198	C++
 	bochs.exe!__crt_seh_guarded_call<int>::operator()<void <lambda>(void),int <lambda>(void) & __ptr64,void <lambda>(void) >(__acrt_lock_and_call::__l3::void <lambda>(void) && setup, _execute_onexit_table::__l22::int <lambda>(void) & action, __acrt_lock_and_call::__l4::void <lambda>(void) && cleanup) Line 199	C++
 	bochs.exe!__acrt_lock_and_call<int <lambda>(void) >(const __acrt_lock_id lock_id, _execute_onexit_table::__l22::int <lambda>(void) && action) Line 882	C++
 	bochs.exe!_execute_onexit_table(_onexit_table_t * table) Line 222	C++
 	bochs.exe!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 211	C++
 	bochs.exe!exit(int return_code) Line 283	C++
 	bochs.exe!__scrt_common_main_seh() Line 262	C++
 	bochs.exe!__scrt_common_main() Line 296	C++
 	bochs.exe!mainCRTStartup() Line 17	C++
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

Most likely, crash happens because at the moment of static object destruction logio is already deleted.

[vruppert]

I have not yet tried to reproduce the issue above, but now I found a solution for the win32.cc issue. Using the value of bx_user_quit makes it possible to call terminateEmul() correctly.

[Vort]

Zero leaks now. Thank you.

I know how to make reproduction of crash easier.
For some reason, Debug MSVC builds of Bochs have NDEBUG defined, which disables assertions.
If I remove NDEBUG for Debug builds, then assertion on this line triggers, no matter how exactly I launch executable:

Bochs/bochs/logio.cc

Line 107 in ca4ca03

assert(n_logfn > 0);