Recent

Author Topic: Unresponsive program  (Read 4719 times)

user5

  • Sr. Member
  • ****
  • Posts: 357
Unresponsive program
« on: June 19, 2018, 07:49:04 pm »
    I have a program made with Lazarus and it generally runs fine but occasionally will become unresponsive, stop interacting with Windows10 and then the computer crashes. The event logs indicate that this program caused the errors.
    This never happens when the same program is run on WindowsXP.
    I did some research and discovered that Application.ProcessMessages can sometimes cause this problem.
    I'm still studying this and I know that many folks have differing opinions about Application.ProcessMessages but from what I've read it seems like this command should only be used when it has to be used. Am I on the right track here or could anyone tell me how to try and track down the cause of this problem? The logs don't give much information.

Thaddy

  • Hero Member
  • *****
  • Posts: 14162
  • Probably until I exterminate Putin.
Re: Unresponsive program
« Reply #1 on: June 19, 2018, 07:53:37 pm »
If you are not using threads *at all* the problem might be related to XP or some left-over code from the Win95- era. Don't expect unsupported platforms to work.
That said: do you have concise working code that reproduces it? That is really important.
Specialize a type, not a var.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Unresponsive program
« Reply #2 on: June 19, 2018, 08:21:01 pm »
    I'm not sure how to answer your question but this program runs fine on XP and Windows7. I know that there are issues involved with older programs running on Windows 10 and indeed I had to make some changes in the program before it would run correctly on Windows 10 but perhaps the queue, processing speed and/or Application.ProcessMessages are all involved here.
    From what I understand so far, it seems like the two examples below are appropriate uses of Application.ProcessMessaages but that I should remove all other instances of this command.

                                                                Waiting for a user response (would it be better to use a timer or something else here?)
        while continue = false do
          begin
            Application.Processmessages;
          end;

                                   Making sure a form is showing completely before continuing
        form75.show;
        Application.processmessages;

    I don't fully understand all the issues involved, like when to use a new thread. One thing... I would think that Windows10 is faster than WindowsXP and this might have something to do with Application.ProcessMessages;

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Unresponsive program
« Reply #3 on: June 19, 2018, 08:24:26 pm »
Code: Pascal  [Select][+][-]
  1. while continue = false do
  2.           begin
  3.             Application.Processmessages;
  4.           end;

That doesn't looks good for me. Maybe yes, you can use a timer instead.

Code: Pascal  [Select][+][-]
  1.     form75.show;
  2.         Application.processmessages;

Well, I can see that the show is not modal, and if you process the messages the form will show, and then your other code will be executed as well, that's desired effect?

BTW form75? You had a lot of forms =)

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Unresponsive program
« Reply #4 on: June 19, 2018, 08:41:22 pm »
    I forgot to mention that these rare crashes have never occurred when the program was waiting for a user response or when a form was being displayed as shown in the examples in the previous posting. The crashes always happened during the regular processing of the program and they always happen in a different part of the program! I'm not sure what that suggests but I'm going to remove most references to Application.ProcessMessages just as a precautionary move.
    BTW: This program has a lot more forms than just 75.

Handoko

  • Hero Member
  • *****
  • Posts: 5122
  • My goal: build my own game engine using Lazarus
Re: Unresponsive program
« Reply #5 on: June 19, 2018, 08:53:32 pm »
Debugging a large project that has more than 75 forms is hard. :o

Bugs can hide in any location on the code. I usually use 'divide and conquer' technique. First I make a backup of the project. Step by step and repeatedly I remove some portions of the code, visual components, units, etc. Until I find out which part that has been removed can stop the crash. Then I will fix the bug on the after 'diet' code. After I managed to fix the bug successfully, I merge the fix back to my 'real' project.
« Last Edit: June 19, 2018, 09:10:40 pm by Handoko »

Thaddy

  • Hero Member
  • *****
  • Posts: 14162
  • Probably until I exterminate Putin.
Re: Unresponsive program
« Reply #6 on: June 19, 2018, 09:00:49 pm »
75 forms is not a mistake perse. 75 forms auto-generated and not on the fly is a huge mistake.
Specialize a type, not a var.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Unresponsive program
« Reply #7 on: June 19, 2018, 09:09:30 pm »
    I have a question... Let's say that you want to delete a huge file like movie1.avi with deletefile('movie1.avi').
    Since the deletion takes more than 15 seconds in this example, does any other processing happen while movie1.avi is being deleted or does it stop until that file is completely removed?

    If some processing and messaging contine while the file is being deleted then wouldn't the following code be undesirable since Application.ProcessMessages would halt all further processing until the file was completely deleted? Would Windows then conclude that the program is unresponsive when it really isn't?

        deletefile('movie1.avi');
        Application.ProcessMessages;

Handoko

  • Hero Member
  • *****
  • Posts: 5122
  • My goal: build my own game engine using Lazarus
Re: Unresponsive program
« Reply #8 on: June 19, 2018, 09:13:23 pm »
Deleting a file should not take that long.

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Unresponsive program
« Reply #9 on: June 19, 2018, 09:16:36 pm »
if deletefile is in the main thread, it will block until it finishes, and then the call of process messages will be called.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Unresponsive program
« Reply #10 on: June 19, 2018, 09:20:20 pm »
        while continue = false do
          begin
            Application.Processmessages;
          end;
While you should avoid it entirely, if you do the above, add a "sleep(50);".
The above loop just runs on full cpu.

As for debugging the issue. There is really no starting point in what you described so far.
But random errors may be caused by either:
- uninitialised vars
- writing to memory that was already freed

So if you have not already done, try the following:
1) Use the option "trash local vars" -gt 
  In fact you should run and test your app with all of the following 4:
    -gt
    -gtt
    -gttt
    -gtttt

2) Use heaptrc  -gh
  This will check for memory issues. You should also try and  set env variable HEAPTRC="keepreleased" (this will use a lot of memory, if your app runs for longer)

3) The "normal" debugging stuff
-Criot -Sa -O-

4) Run and reproduce the issue in the debugger. Maybe there is a crash that you never get to see. The debugger may catch it (or not, but worth a try)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Unresponsive program
« Reply #11 on: June 19, 2018, 09:23:12 pm »
        deletefile('movie1.avi');
        Application.ProcessMessages;

Compile with console -WC
and add debugln
Code: Pascal  [Select][+][-]
  1. uses LazLogger;
  2. ...
  3.         debugln('Start delete');
  4.         deletefile('movie1.avi');
  5.         debugln('End delete');
  6.         Application.ProcessMessages;
  7.  

If indeed the gap between "start" and "end" is that long, then the app would "hang" in that time, but come back to live after.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Unresponsive program
« Reply #12 on: June 19, 2018, 09:49:49 pm »
    Thank you all for your responses. You've given me a lot to think about. If I correctly read the occasional debugging reports on this program then it has no memory leaks but something is causing Windows to sometimes conclude that it is no longer interacting with that program.
    These crashes are extremely rare events without warning and they always happen in a different place in the code.
    Martin_fr, your comment about using a delay really rang a bell with me. I thought about using a short delay in the way you suggested so that the pinging wouldn't happen so fast. As you also mentioned, the program does have a lot of uninitialed variables which I have yet to remove though all of them are local variables, not global. Does "trash local vars" automatically remove uninitialed variables or do I have to delete them one by one?

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Unresponsive program
« Reply #13 on: June 22, 2018, 03:57:12 am »
    I haven't yet found a definitive reason why a Lazarus program of mine would on rare occasions crash the computer it was on but I'm still looking into it. I don't now think it was due to a space being in the path to the program but in case anyone is interested there have been some developments.
    The program detects what Windows version is being used so I made some changes and now whenever it's run for the first time it will prompt the user to run it in compatibility mode for WindowsXP SP3 if the operating system being used isn't WindowsXP or Windows7. It goes on to give instructions for doing that and for disabling the annoying Windows UAC prompt that shows up when the program is run just like with other unregistered programs that don't have a signature certificate.
    Of course, disabling that UAC prompt means that it's disabled for ALL programs but the user is warned about that. Some folks say that it's impossible to disable that prompt for an individual program instead of all programs but others say it can be done if some complicated steps are taken.
    The program has been tested on WindowsXP, Windows7 and Windows10. When it's run in compatibility mode I noticed that its appearance changed slightly in an appealing way and it seems to run just fine that way.
    I did some research on the differences between WindowsXP and Windows7 and found out that Windows7 has a better GUI interface among other things but I hope that they're similar in important ways and that I'm on the right track about this. The program was tested on Windows7 but not nearly as much as on WindowsXP and Windows10. I can only assume that it will work on others.
    This program has never had this problem on WindowsXP.
    Until I can make a definite determination about why the crash happened then this is the way things will be.
    The event logs indicate that the program became unresponsive before the crash happened but this may be a bit misleading. I don't know what the true chain of events were leading to the crash but I've never before seen an unresponsive program cause one of the worse crashes that can occur. It looked like it was working fine and continuously right up to the moment of the crash.
    I'm currently putting the program through extensive shakedown runs to see if it holds up okay while in compatibility mode and I hope that it doesn't crash. If it does then I'll be floored.
    This program is a video editor, movie-maker, cropper and splicer. It can be downloaded from: https://od.lk/f/NDJfMTM3NDQ0OV8
    A file that contains instructions and a log of all corrections and changes can be downloaded from: https://od.lk/d/NDJfMjM2MDM4MV8/readme.rtf
    The program is named VirtualU. Best wishes and all praise to Lazarus.

reinerr

  • New Member
  • *
  • Posts: 37
Re: Unresponsive program
« Reply #14 on: June 22, 2018, 06:05:10 am »
Something that's not clear but from reading I assume this happens on different machines and not just one specific one running Windows 10.

As others have indicated, Application.ProcessMessages can be a problem if you're using threads and synchronizing methods and you can get locks (e.g. calling Synchronize and within the main thread waiting for the thread lock to be available).

But really you should not be waiting for "continue" like this - you should process an event when you are ready to continue.

PS. I don't like the "continue = false" - booleans should not be compared with TRUE or FALSE as they are already are - its like saying "if true = true". If you feel the need to you probably haven't named your variables well. It is better to write "while not continue do".

 

TinyPortal © 2005-2018