Any Known GDI Lockup Issues with Delphi 10.3.2?

[Steve Maughan 26]

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

[Anders Melander 1815]

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.

[Steve Maughan 26]

Here's a video showing the behavior:

 

https://www.loom.com/share/8a00020c3ba440df9a8998dbe17dc1f0

 

Any suggestions greatly appreciated.

 

Thanks,

 

Steve

[Steve Maughan 26]

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

[David Heffernan 2353]

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. 

 

[Anders Melander 1815]

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

[Attila Kovacs 631]

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

[David Heffernan 2353]

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. 

[Steve Maughan 26]

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

[Steve Maughan 26]

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