Program freezes when not linked to debugger

[dormky 1]

I have some code doing imports and updating the UI as it goes.

When running with the debugger attached, everything goes fine. But running the exe itself (the exact same exe that was just compiled for the debugger run), the UI freezes. What's weird is that it only starts doing this after a few seconds, and not in the same place everytime either.

What's going on here ? Has anyone encountered this before ?

 

I can see the logs as the exe runs (with its UI frozen), so I know the code is still working fine.

 When I say "frozen", I mean that Windows whites it out and if you click on it, it will say that the program isn't answering.

Edited October 16, 2023 by dormky

[stijnsanders 35]

Looks like normal behaviour like you describe it: Windows will 'white out' applications and show them as non-responsive, when they stop reading messages from the message queue. In Delphi applications, there are two main ways to solve this: either call Application.ProcessMessages from time to time from the code that does the processing. There's some special care you'll need to take for the case when the user wants to abort the importing, or close the application. This will 'unfreeze' the application, because messages get handled, but may slow down the importing a little.
The second way is to write the importing code so it uses background threads. There are libraries and solutions that can help you with this, or the hard way is inheriting from TThread yourself, but then you need to know how to synchronize between the main thread to output progress and results from the importing.

[dormky 1]

Application.ProcessMessages() does not apply as a solution here.

As I said, the freezing occurs after a few seconds ; before then the UI updates perfectly fine. So the application does process the messages, it's just that for some reason it stops after a while. Generally after 5-8sec.

[Brian Evans 83]

Without a way to reproduce it could be a lot of things. Seen code skip a step in a process when a debugger was attached that was added to speed up debug runs looking at latter steps. 

 

Also, time the freeze - a consistent over X seconds can be helpful to indicate if it is a timeout like looking up a network name or trying to initiate a network connection to something that doesn't respond at all.

[Kas Ob. 91]

On 10/16/2023 at 5:27 PM, dormky said:

I have some code doing imports and updating the UI as it goes.

When running with the debugger attached, everything goes fine. But running the exe itself (the exact same exe that was just compiled for the debugger run), the UI freezes. What's weird is that it only starts doing this after a few seconds, and not in the same place everytime either.

What's going on here ? Has anyone encountered this before ?

You did not mention if there is background thread, also more details will help, like importing from files on local disk, network disk, internet ....

When running with debugger how much time does it take ?

 

so many details may be you are missing, and we are gonna just guess.

 

Brain answer is right on point, and i want to add one more situation where i saw more or less similar behavior, you most likely have loops and checks processing these data, and one critical variable is not initialized, like, a situation where inside the debugger the value by default is X (may be 0 or just something) and without the debugger it is not X, so the fast way to check is after running and application and it went white (froze), attach the debugger and try to make sense from the stack, step and run and follow the main thread running. 

or generate a detailed log for your loops, every loop or just log the import and process in few checkpoints and follow which one is the faulty then expand on that section with more logging, you can use DebugOutputString or any other logging method, all will do.

 

[Renate Schaaf 64]

MadExcept can check for frozen main thread, with or without debugger. Just surprised nobody mentioned it.

[Kas Ob. 91]

7 hours ago, Renate Schaaf said:

MadExcept can check for frozen main thread, with or without debugger. Just surprised nobody mentioned it.

It will detect frozen GUI, aka not responding, which is clearly visible, so its report as frozen is useless in this case, also will not report rouge while loop going for full 32 bit or 31 bit integer, or just failed code to increase or .... only human can detect broken algorithm.

[dormky 1]

The main thread is not frozen, the data is still being imported. It's just the UI that freezes after a few seconds.

If the lack of call to Application.ProcessMessages() was at fault, the freeze would be immediate, but it's not, I can see rows getting added in the UI... until I can't because of the freeze.

 

@Kas Ob.It's not done in a background thread. I would have mentioned it if it was. Same thing with the running time, it's the same in both instances.

[Kas Ob. 91]

2 minutes ago, dormky said:

If the lack of call to Application.ProcessMessages() was at fault, the freeze would be immediate, but it's not, I can see rows getting added in the UI... until I can't because of the freeze.

 

@Kas Ob.It's not done in a background thread. I would have mentioned it if it was. Same thing with the running time, it's the same in both instances.

Yet, you didn't mention how the import happen, here an imaginary scenario that will generate that behavior (more or less), if your application grabbing these imported data from internet and using event based network, then the data will come as message and will interfere with other messages, causing a growing delay, this will accumulate till the message queue is full or just the delay getting greater for the OS to detect it right away but after a while the respond from the application the OS decide it is frozen.

 

as a solution in all cases switch to background operation, and don't use Application.ProcessMessage, it will save you great headache later and most likely should be removee it eventually.