Memory leak in IconUtils or in my code?

[cipri]

I have written a little Test-Application. You can compile with the command "jam" (on gcc4). After you start the program "test", look how much memory it takes. Then make the window bigger and smaller (the more often the better you see the difference) a few times. Now look again at the memory it takes.

the relevant code lies in Tool.cpp, ImageButton.cpp

My conclusion is: I do something wrong in "LoadBitmap" or the IconUtils indeed have a memory leak.

(I'm using one of latest r1a3 builds)

[ribbonz]

It's so funny that you posted this. Because I was about to make a similar bug report, also with an attached test program.

In my case, it was a call to BTranslationUtils::GetBitmapFile() that was the culprit. My little test program would accept a dropped image file and display it. Every re-paint of the window would cause the memory to grow and grow and grow and grow...

I found a workaround solution for my test app. But a funny thing happened. I tried both original and fixed versions on another machine with an older Haiku revision (40242) and neither had any memory leaks. I'm currently using 41667, so I installed this newer version on my other machine -- so that I could compare apples to apples. Still no memory leaks.

So just now I tried your test program and, sure enough, it leaks memory like crazy on my main machine. And then I tried it on the other machine, and it doesn't leak at all.

In other words, both my test program (unfixed version) and your test app both leak like crazy on my main Haiku machine. But neither leak on my secondary Haiku machine -- which is now at the same revision.

So perhaps there is some memory leak problem in BBitmap, or something in the app_server framework. But it may be specific to certain hardware or graphics cards. Oh, and both of my machines use the default Vesa driver for Haiku.

[ribbonz]

test app for dealing with memory leaks using GetBitmapFile()

[ribbonz]

cipri: try this

Open Screen Preferences and change your screen resolution for the current workspace to something else, and Apply. Then change it back it its original setting and Apply. Then reboot.

The reason I suggest this is that I just did this -- by accident -- and it seems to have helped the memory leaking on the test apps (yours and mine). I was fiddling around with changing the screen resolution in another workspace and accidentally did it for All workspaces. So when I went back to the first workspace, I realized the error and set it back. A bit later, I rebooted, and shortly after tried the test apps again for grins.

I can't say that the memory leaking stopped -- it hasn't. But it appears to be dramatically slower than it was. But maybe the screen resolution change and reboot was only a coincidence. It's got me wondering.

[cipri]

ribbonz: I also noticed, that sometimes the memory leak is not that bad, and sometime it can be quite bad.

If you want to experience how bad it can be, try my new game ​http://haikuware.com/directory/view-details/games/board/puri-master-of-chess-v02

[bonefish]

Which team does leak the memory, the application or the app server? Please add the output of listarea for that team, once at the beginning, once after some leaking has been going on.

[ribbonz]

ok, got some listarea output for my test program

I first tried this morning and could not induce a memory leak. The program did jump up a few times, and then settled down at around 128MB and wouldn't budge from there. No matter what I threw at it, or how many re-paints I caused.

So I stopped the program and went on to other things. Then about a half hour later, I tried again. This time, it started leaking pretty easily. So I stopped it again, brought out Terminal, and then captured some listarea output.

I'm don't understand all the output, but it does look as though 'server_memory' is going kinda crazy.

[ribbonz]

listarea output while ImageDrop test program was running

[bonefish]

I believe those "server_memory" areas are used as shared memory for various kind of data shared between the application and the app server. CCing Stippi who might have a clue.

[axeld]

Can you please retry with hrev41983 or later if that changes anything? If not, are you compiling Haiku yourself, and could test a patch that adds a little debug output?

[ribbonz]

No, I don't build Haiku. I just download and install the anyboot images.

But I'll be happy to try out your fix in 41983 as soon as I can get it (when it shows up on the anyboot download page).

[ribbonz]

I just installed hrev42061. So first thing, I tried my test ImageDrop app to see if Axel's attempted fix in 41983 would make any difference.

Unfortunately, it didn't. The program still leaks memory like crazy. Each re-paint of the window jumps up the usage.

I'm attaching the listarea output after running the test in in the new revision.

[ribbonz]

listarea output of test program after attempted fix in 41983

[cipri]

i guess this one can be closed. The effects are gone.