GDIPlus related crashes

[AAraya]

I've been using several different user controls from various authors on here which use GDI+. I love how they help me modernize my UI. But I've been seeing random crashes in my own testing and some users report the same. When I examine the crash dump files they always have something to do with GDI+. I'm going to have to go through those user controls which I didn't write to try to debug and fix them.

Some questions for those of you who are experienced with GDI+:

What are the best practices when using it in for memory and resource management?
What are some common gotchas that I should look for?
How would you try to debug these crashes which are not reproducible and seem to happen randomly?

[Elroy]

I've gotten my head around sections of GdiPlus in the past, but it's been a while. What I do remember is that, by Microsoft's own admission, they are "low level" API calls. As such, it's up to the caller to do a great deal of memory (and handle) management. And, if that's not done correctly, it's extremely easy to create major memory leaks, and possible crashes.

Beyond that, when I follow all the recommended ways to use it, I've never had any problems with it. But it does require thorough alpha-testing, making sure edge-cases are tested.

In the past, I have thought about developing wrapper classes, but the GdiPlus is so vast that it just becomes unwieldy to do that. So, I always wind up just writing procedures to do the specific tasks I'm after for a specific application, creating some global variables for initialization and other broad things.

[Niya]

What are the best practices when using it in for memory and resource management?

Aside from obvious advice like making sure to free resources you've allocated, I'd say a very big one is to always check the return values of API calls. Never ever assume they will never fail. Even if they succeed 99% of the time, that 1% will trip you hard when it happens and it will be a pain to track down.

What are some common gotchas that I should look for?

There aren't really that many gotchas. Memory management is simple, you allocated something, you must free it eventually. If I must suggest something to look out for, I'd probably say off-by-one errors. If you allocate a buffer one byte too small and end up writing past the end of the buffer, this will induce an access violation sometimes and crash your program.

How would you try to debug these crashes which are not reproducible and seem to happen randomly?

In my VB6 days I'd track down these kinds of bugs by a narrowing search. I'd start with a best guess about where it might be happening and set breakpoints. If the code crashes before hitting the breakpoint, I'd narrow it down by putting the breakpoint closer to the start of the execution path. I repeat this until I reach a point where the code doesn't crash before hitting the breakpoint and then I'd have a reasonable window within which I may locate the bug.

If it happens too randomly, you might want to start logging. Have your code write to a log so when the random crash doesn't happen the log will help you track down where it might be. Log everything your application does. How detailed the log should be is entirely up to you and when the crash happens you may get lucky and see some abnormality in the logs that will point you in the right direction.

[Niya]

To expand upon my suggestion about logging consider the following:-

Private Sub Form_Load()

    Dim num As Variant
    Dim start As Double
   
    start = 45
    Debug.Print "Start variable set..."
    
    num = Array(12, 3, 8, 13, 9)
    Debug.Print "Array has been initialized with values..."
    
    Debug.Print "Beginning loop..."
    For Each n In num
        Debug.Print "Number retrieved: " & CStr(n)
        start = start / n
            
        Debug.Print "Division successful. Result: " & CStr(start)
    Next
    Debug.Print "Loop ended..."
    
    Debug.Print "Calculation finished."

End Sub

The above code runs successfully and outputs the following log:-

Start variable set...
Array has been initialized with values...
Beginning loop...
Number retrieved: 12
Division successful. Result: 3.75
Number retrieved: 3
Division successful. Result: 1.25
Number retrieved: 8
Division successful. Result: 0.15625
Number retrieved: 13
Division successful. Result: 1.20192307692308E-02
Number retrieved: 9
Division successful. Result: 1.33547008547009E-03
Loop ended...
Calculation finished.

The log shows a successful run.

Now let's change one of the values in the array to be 0:-

num = Array(12, 3, 0, 13, 9)

The above would induce a division by zero error. Let's pretend that division by zero just crashes your application with no warning so now you have to rely on the logs to help you track it down. This is what the log would look like now:-

Start variable set...
Array has been initialized with values...
Beginning loop...
Number retrieved: 12
Division successful. Result: 3.75
Number retrieved: 3
Division successful. Result: 1.25
Number retrieved: 0

The above log tells you that the variable and array were initialized with no problems and the loop was started. It also tells you that the loop was iterated but not to completion. So now you know that the bug is in the loop.

This is essentially how logs help you track down bugs.

[yereverluvinuncleber]

Niya knows what he is talking about.

Use Process Explorer, a free util. to view the properties of the process dynamically. You know what your program is doing or what it is meant to be doing. Watch it dynamically and see when it starts to consume resources. Look at the handles section and see which type of handle increases significantly.

This was also recommended to me in the past:

http://www.nirsoft.net/utils/gdi_handles.html

as was this: https://www.vbforums.com/showthread....-and-Detection

Really, it comes down to line-by-line digging and tracing to find out the gdi+ clean up routines (if any) to see under which conditions they are being bypassed leaving handles un-closed and dangling. Often, it can come down to any other badly-written routine consuming handles and memory in some other fashion resulting in a GDI+ error later when no memory is available. I know this because thomething thimilar was occurring in my own GDI+ project.

[wqweto]

GDI+ leaks are scary. You don't get to realize anything is wrong until GDI+ shutdown is called.

Imagine you underallocated a buffer like in above example but you don't get immediate crash, not until you try to close your form. Now go find which allocation was rogue, almost impossible IMO.

cheers,
</wqw>

[AAraya]

Thanks for the hints all. I'll leave this open for a little while longer in case anyone else wants to add to it but I've got enough to get me started.

[baka]

my own advice is to stay away from user controls that people share.
create your own.
and u do that carefully and only add the things U need.
but, since u do that why not just use Direct2D and WIC.

if u want to stay in GDI+, theres TONS of examples here. so theres plenty of sources to learn from.

[zx81sp]

I've been using several different user controls from various authors on here which use GDI+. I love how they help me modernize my UI. But I've been seeing random crashes in my own testing and some users report the same. When I examine the crash dump files they always have something to do with GDI+. I'm going to have to go through those user controls which I didn't write to try to debug and fix them.

Some questions for those of you who are experienced with GDI+:

What are the best practices when using it in for memory and resource management?
What are some common gotchas that I should look for?
How would you try to debug these crashes which are not reproducible and seem to happen randomly?

I'm also use a few of those controls. The best solution I've found is...fix the code.

[SomeYguy]

I specialize in graphics applications and most of my code uses GDI+ in some way. As others have said, be careful to free resources where appropriate i.e graphics objects, image handles, font objects etc. and all should be well.

I like Niya's idea of a trouble log. I've never had any significant problems with GDI+ but I might write such a log into some of my code just in case.

If using custom controls which have been posted here, look very closely at all of the relevant code to make sure that everything is done properly. Even the best, most talented programmers can make mistakes. In which case we must hunt down said programmer and flog him/her with a wet noodle .