Opened 9 years ago

Closed 9 years ago

#7632 closed bug (fixed)

Memory leak in IconUtils or in my code?

Reported by: cipri Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc: stippi
Blocked By: Blocking:
Platform: All


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)

Attachments (4) (99.5 KB ) - added by cipri 9 years ago. (8.6 KB ) - added by ribbonz 9 years ago.
test app for dealing with memory leaks using GetBitmapFile()
imagedrop_listarea_output.txt (47.6 KB ) - added by ribbonz 9 years ago.
listarea output while ImageDrop test program was running
imagedrop_listarea_output2.txt (18.2 KB ) - added by ribbonz 9 years ago.
listarea output of test program after attempted fix in 41983

Download all attachments as: .zip

Change History (15)

by cipri, 9 years ago

Attachment: added

comment:1 by ribbonz, 9 years ago

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.

by ribbonz, 9 years ago

Attachment: added

test app for dealing with memory leaks using GetBitmapFile()

comment:2 by ribbonz, 9 years ago

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.

comment:3 by cipri, 9 years ago

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

comment:4 by bonefish, 9 years ago

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.

comment:5 by ribbonz, 9 years ago

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.

by ribbonz, 9 years ago

listarea output while ImageDrop test program was running

comment:6 by bonefish, 9 years ago

Cc: stippi added
Version: R1/alpha2R1/Development

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.

comment:7 by axeld, 9 years ago

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?

comment:8 by ribbonz, 9 years ago

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

comment:9 by ribbonz, 9 years ago

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.

by ribbonz, 9 years ago

listarea output of test program after attempted fix in 41983

comment:10 by cipri, 9 years ago

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

comment:11 by korli, 9 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.