Jump to content
Steve Maughan

Any Known GDI Lockup Issues with Delphi 10.3.2?

Recommended Posts

My mapping program is a VCL app that makes extensive use of GDI drawing to draw the map. I've recently upgraded from Delphi 10.2.3 to 10.3.2. The version compiled with Rio will often lock up after being used for 20 minutes. The app becomes unresponsive for about 15 seconds. In that time the CPU utilization is close to zero and the memory usage doesn't change. After the lock-up it will sometimes become fully responsive or in some case will only be responsive for a moment. There are no error message during or after a lockup. The application is compiled as 64 bit and uses about 1.6 Gb of memory while the test machine has 32 Gb i.e. it's not short of memory.

 

What could cause the lockup? 

 

My first thoughts is it's something to do with GDI. Has anything changed with GDI in Delphi Rio compared to Delphi Tokyo?

 

Or maybe it's a virus scanner. I use Panda Dome. I'll switch it for something else to see if that's the problem.

 

Or could it be Windows 10 messing with the memory allocation? I've just updated to Windows 1909.

 

I know it's a long shot but any suggestions are welcome.

 

Steve

Share this post


Link to post

If you can reproduce the problem then simply run the application in the debugger, break when the problem occurs and examine the callstacks.

 

...however; My usual advice when people experience this kind of progressive or periodic slowdown/lockup is to uninstall the various cloud storage services they have running (ITunes, Google Drive, OneDrive, etc.). Solves the problem in 9 out of 10 cases.

Share this post


Link to post
1 hour ago, Anders Melander said:

If you can reproduce the problem then simply run the application in the debugger, break when the problem occurs and examine the callstacks.

 

...however; My usual advice when people experience this kind of progressive or periodic slowdown/lockup is to uninstall the various cloud storage services they have running (ITunes, Google Drive, OneDrive, etc.). Solves the problem in 9 out of 10 cases.

Hi Anders,

 

I took your advice. There was nothing on the call stack, even in debug mode:

 

 

Interestingly, after the freeze I started Loom and SnagIt to record the video. Both wouldn't start until AlignMix was unfrozen. To me this implies it's something to do with Windows 10.

 

Thanks,

 

Steve

Share this post


Link to post

Use process explorer or process hacker to see if you are leaking gdi objects. Use madExcept leak detection tool which detects all sorts of leaks. You need to try to narrow things down. 

 

Share this post


Link to post

You need to examine the call stack of all the threads.

When you break the call stack is just shown for the currently active thread which is rarely the one you're interested in.

 

P.S. I can see from your video that you have DropBox installed...

Share this post


Link to post
1 hour ago, Steve Maughan said:

To me this implies it's something to do with Windows 10.

or driver or hardware..

btw. taskmanager has a ton of extra columns in options, GDI objects too, but this is something else

Share this post


Link to post
1 hour ago, Steve Maughan said:

To me this implies it's something to do with Windows 10.

Usually that's wishful thinking.

 

What happens next in this thread is that people spend many days suggesting all sorts of things that could be. That doesn't tend to be very productive. Guesswork seldom proves effective. We all know this to be true, and still we do it. 

 

Getting a stack trace from all threads in your process, during a lock up would help. Again, madExcept would give you that with madTraceProcess. 

  • Like 1

Share this post


Link to post

HI David, Anders & Attila,

 

Thanks for the input - I really appreciate it. I've recompiled with Tokyo 10.2.3 and the problem seems to have gone. I'll need to investigate further.

 

I have madExcept so I'll see if that helps first.

 

Thanks again,

 

Steve

Share this post


Link to post

I finally got to the bottom of this error. It's a bug in the Parallel Programming Library that ships with 10.3.2 and 10.3.3.

 

Here's what happened...

 

After I downgraded to 10.2.3 I was just pleased that the freezing stopped. I was also concerned that I'd be stuck using 10.2.3 for ever. So this week I upgraded again; this time to 10.3.3 in the hope the bug didn't show up in this version (the bug had initially appeared in 10.3.2). Unfortunately it showed up—I was gutted! I tried replacing the memory manager - that didn't work. I tried checking for resource leaks; there weren't any. I then switched the main rendering routine to use OmniThread instead of the PPL and that corrected the bug. It seems that after being under load, and then left for a while, the PPL's can suspend some threads for a period of up to 1 minute. If the suspended thread is in a "for" loop the program freezes. Eventually the application comes back to life but it happens repeatedly. The bug wasn't present in 10.2.3 but was present in 10.3.2.

 

I'm elated that the bug is gone!

 

Steve

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×