Given the following command:
$ c1541 -format speed-test,00 d64 speed-test.d64
returns the following memleak warnings:
formatting in unit 8 ...
archdep_join_paths.c:80: Warning: Memory block(s) allocated here was not free'd (Memory leak with size 0x1d at 0x7fcf72003200).
callstack:
1 c1541 0x0000000105e43f25 lib_calloc_pinpoint + 469
2 c1541 0x0000000105e4c230 archdep_join_paths + 272
3 c1541 0x0000000105e4c95d archdep_user_config_path + 45
4 c1541 0x0000000105e4ba0f archdep_create_user_config_dir + 15
5 c1541 0x0000000105e4b873 archdep_init + 19
6 c1541 0x0000000105e3e057 main + 55
7 libdyld.dylib 0x00007fff943aa5ad start + 1
8 ??? 0x0000000000000005 0x0 + 5
Total memory leaks: 1 in 1 lines. Total bytes leaked: 0x1d (29B).
max. total memory that was allocated: 0xaab9 bytes. (42KiB)
Top 50 largest allocated blocks:
2458 bytes (9KiB) allocated at c1541.c:4749
2458 bytes (9KiB) allocated at c1541.c:4749
2458 bytes (9KiB) allocated at c1541.c:4749
2458 bytes (9KiB) allocated at c1541.c:4749
15c8 bytes (5KiB) allocated at c1541.c:1076
100 bytes (256B) allocated at vdrive.c:101
100 bytes (256B) allocated at vdrive.c:317
80 bytes (128B) allocated at ioutil.c:204
50 bytes (80B) allocated at zfile.c:165
48 bytes (72B) allocated at util.c:85
30 bytes (48B) allocated at fsimage-create.c:381
30 bytes (48B) allocated at diskimage.c:468
20 bytes (32B) allocated at fsimage-create.c:382
20 bytes (32B) allocated at fsimage.c:105
1d bytes (29B) allocated at archdep_join_paths.c:80
18 bytes (24B) allocated at archdep_join_paths.c:80
18 bytes (24B) allocated at archdep_join_paths.c:80
18 bytes (24B) allocated at log.c:238
10 bytes (16B) allocated at archdep_home_path.c:111
10 bytes (16B) allocated at log.c:238
10 bytes (16B) allocated at util.c:85
10 bytes (16B) allocated at vdrive-command.c:109
10 bytes (16B) allocated at cbmdos.c:158
f bytes (15B) allocated at fsimage-create.c:388
f bytes (15B) allocated at fsimage.c:61
f bytes (15B) allocated at util.c:594
c bytes (12B) allocated at log.c:241
b bytes (11B) allocated at vdrive-command.c:983
8 bytes (8B) allocated at log.c:238
8 bytes (8B) allocated at log.c:241
6 bytes (6B) allocated at log.c:241
I cannot reproduce this on either Linux or Windows with current trunk. Which 3.3 did you use? The 3.3 tarball, or current trunk?
3.3 as released - the tarball. Also, AFAIR you need to add
configureflags to enable these messages.--enable-debugAFAIR.Fixed in r36101. The leak was in SDL's archdep_shutdown(), while I was staring myself blind on the Gtk archdep code. Probably should have asked which UI you were using :)
Anyway, the fix is a one-liner: add
archdep_user_config_path_free()to src/arch/sdl/archdep.c insidearchdep_shutdown()if you want to fix the bug in the 3.3 source.Heh - yeah - didn't think about the UI either. Otherwise I'd state it in the original description. Thanks for the fix and yes, I'll apply it to my sources.
Cool. Let me know if that fix works, then I can close this.
And thanks for reporting the bug.
I added the line in question at the end of the said function and yes, it seems to have fixed the c1541 leakage. OTOH I just noticed that the emulator(s) themselves generate lots of leaks. It would be good to check them too. An example running x64sc:
If you choose so, I might add another ticket of course.
I think all those leaks were plugged in current trunk. I don't get any of them in either Linux or Windows. And Linux uses the same codepath as MacOS (at least as far as I know).
But if you feel adventurous, you could try checking out trunk and compiling from that to see if the leaks are still there :)
I'll compile the current trunk and let you know here. Probably tomorrow.
Checked out (with many problems - sf sucks all the time) and compiled the repo version. It's still leaky:
Hmm, when I trigger the monitor. and do the following:
I get 6 leaks in 3 lines, one in uimenu.c and the rest in mon_lex.l when using the SDL port, I get 40 leaks in 4 lines using the Gtk3 port and the VTE monitor, this time in uimenu.c (I know about this one: somehow Gtk doesn't clean up the GClosure instances), uimon.c and a few in mon_lex.l again.
1097 leaks seems excessive, are you using -moncommands or so?
Yes, moncommands is used in this case. It loads the labels.
I can see where the leaks happen, but it won't be easy to fix. Looks like actually freeing memory was only an afterthought.
I'm closing this bug since the original issue was fixed a long time ago. I've opened a new bug about the leaks in the monitor: bug #1936.