[RESOLVED] outOfmemoryException

[KMDcomp]

I wrote a program that needs to show a jpeg image in a picture box whenever a new item is selected from a combo box.

It works fine most of the time, but sometimes throws the out of memory error. Sometimes I can make it through the whole list of pictures, and sometimes I can only make it halfway. The images themselves are all fairly close in size.

Anybody ever have an issue like this?

[Shaggy Hiker]

That usually arises when you have an infinite loop, but in a handheld, with the more limitted memory, you could be getting it depending on how objects are being created and destroyed.

I would recommend examining how you use objects, and making sure that you are properly disposing of everything.

It is unfortunate that the error appears to be inconsistent. If it is frequent, and you can get it to happen in a debugging session, then I would suggest looking at the stack when it occurs. If you are MANY MANY levels deep in a recursive call, or have a LONG string of calls within calls within calls, then you have located your problem. Fixing it might not be so easy, but identifying it is half the battle.

[KMDcomp]

Thanks for helping track this down Shaggy.

While the crash doesn't happen consistently, the line it crashes on is consistent. pic = new bitmap(picPath)

When the program first loads, it uses 1.75 mb of program memory

When the program loads its first image, it goes up to about 3 mb of program memory.

When the program crashes, it shows 40 mb of memory being used.

If I check the memory while I'm flipping through pics, it shows a fairly consistent 3 mb of use.

When the SelectedIndexChanged code runs, no loops are executed in the method or in any of the objects that I created.

How do I look at the stack? I can get it to happen by flipping through the pics for 1 to 2 mins.

[Shaggy Hiker]

That last line alone makes the whole thing sound like a case of not disposing of things properly. The stack should be valuable. As to how to get there, I believe there are a few different routes depending on exactly how you have visual studio set up. It looks like the Call Stack button is located on the debug toolbar, and looks like a series of three windows overlapping down to the right.

Once you open the stack, you can see the sequence of calls that got to the point you are at. You can click on any of those calls, and view the source in that function that called the next function, which is where execution will continue once the nested call returns. In most cases, you are not very far into the stack. If you are really deep into a series of nested calls, that would be somewhat suspicious.

However, that is not the only possibility. That mostly would show you recursive calls or nested calls (such as if object A calls object B which calls A again), which sounds somewhat less likely in this case. More likely from your description is simply that some objects are being created and not disposed correctly. My suspicion would lie with the bitmap, but only because that object could grab a significant chunk of memory with each bite. I don't have a good suggestion as to how to look for such a thing. There are just too many possibilities.

[KMDcomp]

Problem solved!

I talked to a friend of mine the other night, he had a similar problem with a program that needed to be able to flip through pictures. It was as you suggested Shaggy. The garbage collector wasn't killing off old objects fast enough. He suggested either putting a small pause in the program or calling the garbage collector directly at the end of the method that retrieves the picture. Both methods work well. I can now zip through the picture list as quickly as I want with no issues.

[Shaggy Hiker]

Great, and good to hear the tip. I suspect this is largely a portable problem, where small amounts of memory tax the GC routines. I may make use of that knowledge myself one of these days.