Lazarus
Programming => Operating Systems => Windows => Topic started by: lainz on January 25, 2021, 03:00:03 pm
-
Hi, we have a program, a point of sale system, that has two problems under Windows:
1) In some machines it won't start, it requires sometimes to restart Windows
2) When closed, sometimes it leaves a ghost process, that should be killed with the task manager
The second is bad when we're building it with Lazarus, since the same executable can't be overwritten if it's running. I mean run without debugging, that's the fast run.
Maybe a memory leak?
We use a lot of stuff, internet connection, websockets, printers, local http server, all in a single executable.
About the first, we have no idea of why that happens.
Any ideas, someone had the same problems?
-
hello,
have you some threads in your program ?
have you tried to disable some parts of your program ( for example the http server) ?
Friendly, J.P
-
Hi, yes we have threads and also sqlite.
I noticed for example that if I want to delete the database file when the ghost process is running I can't.
Yes the problem is starting the application, the http server starts later. So it doesn't show the login page :S It should only load the settings file and run the login form. The main form is even not created at that time.
-
Not enough info for pointing in a direction.
As a solution to at least see witch thread is not terminating (maybe no timeout on a socket connection?), i would write to a log file (or console / terminal) the name of the (every one separately) thread after the "if not terminated" loop to see witch one is missing and causing the ghost process...
-
A suggestion.
Sometimes, I have also experienced startup problems with GUI apps.
The trick that works for me: use Application.QueueAsyncCall.
In FormCreate, the GUI is initialized. The last call inside the constructor:
Application.QueueAsyncCall(@somesensitivecodelikeserverstartups,0);
Might work for you also.
-
Hello.
Did you try to compile without any optimization ( without O-. )?
And using cmem as first unit in uses section of program unit?
Sometime it helps.
Fre;D
-
1) In some machines it won't start,
What do those machines have in common ? Windows version ? limited memory ? limited free disk space ? ssd instead of mechanical hard drive (timing issue) ?
it requires sometimes to restart Windows
That's quite unusual. Does Windows freeze ? Do programs that were started before it continue running ? if yes, running "process explorer" or "process hacker" may provide some clue as to what is happening (check the consumption of every resource type.)
2) When closed, sometimes it leaves a ghost process, that should be killed with the task manager
In the closing code, is the executable waiting for something from another thread or process ?
Maybe a memory leak?
the symptoms you describe are unlikely to be caused by a simple memory leak even if it is a really bad one.
We use a lot of stuff, internet connection, websockets, printers, local http server, all in a single executable.
It sounds like the program uses some synchronization mechanisms. If something "fails" then the program may be left waiting for something that will never arrive.
About the first, we have no idea of why that happens.
@Bram71's suggestion of logging the various steps in the startup process (and close process) could be helpful.
HTH.
-
Hi, we have a program, a point of sale system, that has two problems under Windows:
...
Any ideas, someone had the same problems?
In addition to the suggestions you have received already, I would highly suspect an antivirus application is holding on to files or processes at various times.
I would recommend that you go to www.sysinternals.com (a Microsoft site) and download, in particular, HANDLE.EXE
You will be able to use this app to check for open file handles on your file or folder, and see what is holding on to the process.
-
I dont know, if this is a proper solution for you but:
If the program is closing call the Windows API function "ExitProcess". This terminates all child threads, even those which are I/O waiting.
It closes all Handles, might this be file- thread- mutex- or processhandles and the process itself.
It will not terminate Child processes, but detach them.
BTW, console processes are always implicitely terminated by a final call to "ExitProcess" by windows, but not GUI processes
If some child threads are still running, it might vanish from the screen and close its windows, but if "ExitProcess" is not called it will stay in memory invisibly waiting for the threads to terminate.
If building in Lazarus the exe file cant be rewritten after compilation, because it is locked as long as the process runs because windows needs it for paging. (It is however possible to rename or move the file while it is open)
All is said by me so far I know and have experienced, without warranty.
-
Have you tried to attach a debugger to the hanging processes? Get any info what they are doing?
As for starting up (or rather the cases were starting up is not happening).
Try to see if they exit with an error code. In Lazarus trunk, the debugger now can report this.
In 2.0.x, when using the GDB debugger, maybe: Menu View > Ide Internals > Debug Output, and see what gdb says when the process stops.
Or if it does not exist, but hangs forever: try get a stacktrace.
-
Have you tried to attach a debugger to the hanging processes? Get any info what they are doing?
As for starting up (or rather the cases were starting up is not happening).
Try to see if they exit with an error code. In Lazarus trunk, the debugger now can report this.
In 2.0.x, when using the GDB debugger, maybe: Menu View > Ide Internals > Debug Output, and see what gdb says when the process stops.
Or if it does not exist, but hangs forever: try get a stacktrace.
Hi, I think it will be the best to do, since It happens sometimes, and I can't reproduce right now, but it happens.
How I can attach a debugger to the process?
I dont know, if this is a proper solution for you but:
If the program is closing call the Windows API function "ExitProcess". This terminates all child threads, even those which are I/O waiting.
It closes all Handles, might this be file- thread- mutex- or processhandles
It will not terminate Child processes, but detach them.
BTW, console processes are always implicitely terminated by a final call to "ExitProcess" by windows, but not GUI processes and the process itself.
If some child threads are still running, it might vanish from the screen and close its windows, but if "ExitProcess" is not called it will stay in memory invisibly waiting for the threads to terminate.
If building in Lazarus the exe file cant be rewritten after compilation, because it is locked as long as the process runs because windows needs it for paging. (It is however possible to rename or move the file while it is open)
All is said by me so far I know and have experienced, without warranty.
Hi, Where in the program you can put the ExitProcess call, in a GUI application?
Hi, we have a program, a point of sale system, that has two problems under Windows:
...
Any ideas, someone had the same problems?
In addition to the suggestions you have received already, I would highly suspect an antivirus application is holding on to files or processes at various times.
I would recommend that you go to www.sysinternals.com (a Microsoft site) and download, in particular, HANDLE.EXE
You will be able to use this app to check for open file handles on your file or folder, and see what is holding on to the process.
Yes we think on that too, but all we have in common Windows Defender on Windows 7 or Windows 10.
-
How I can attach a debugger to the process?
Use the "attach to program" in the "run" menu.
Hi, Where in the program you can put the ExitProcess call, in a GUI application?
A program can call "ExitProcess" anywhere, anytime, GUI or otherwise for whatever reason. There are no restrictions on when and where that API can be called.
-
How I can attach a debugger to the process?
Use the "attach to program" in the "run" menu.
Hi, Where in the program you can put the ExitProcess call, in a GUI application?
A program can call "ExitProcess" anywhere, anytime, GUI or otherwise for whatever reason. There are no restrictions on when and where that API can be called.
Thankyou, I will try to debug it, and if I can't find a solution I will use the ExitProcess.
-
BTW, if your program doesnt terminate cleanly and you have to press the red "Stop" button in the debugger,
then "Exitprocess" at the end of the program will help.
If this is a clean Solution or a quickndirty fix, depends, only you can judge it.
As said, console processes always terminate this way.
-
As said, console processes always terminate this way.
Just for the record, all processes that end _normally_ whether console or GUI, end with a call to ExitProcess. In a language such as Pascal, the call is not visible because it is part of the RTL. Also, there are other ways to terminate a process but none of them are considered normal and/or desirable.
In the case of Pascal (and many other languages such as C and C++), the "disadvantage" of calling ExitProcess in the application itself is that the language's RTL does not get a chance to do any cleanup of any internal resources it may be using. This is a "non problem" because whatever the RTL failed to cleanup, the O/S will clean up.
-
The hook is readily available, see: https://www.freepascal.org/docs-html/rtl/system/exitproc.html
Mind the use of sysutils may want you to chain the order, but the hook is there.
-
As said, console processes always terminate this way.
Just for the record, all processes that end _normally_ whether console or GUI, end with a call to ExitProcess. In a language such as Pascal, the call is not visible because it is part of the RTL. Also, there are other ways to terminate a process but none of them are considered normal and/or desirable.
Recently I had a C++ Windows GUI program, dealing with threads, that did not fully terminate, because not all Threads where terminated.
The threads where I/O blocked and could not self terminate.
I tested the behaviour of a Free pascal Program with threads and indeed it terminates when the close button is pressed despite threads running.
In this case however, gdb does not terminate, so there is still something wrong. At a subsequent debug session there are problems.
(I started the thread with BeginThread, dont know if that matters) Now I must reboot, all ghost processes removed, but still problems with debugging. ;D
the debuggee terminates not, if an unhandled exception e.g. 1/0 happens.
So a call to Exitprocess in an exception handler could be required in this case.
-
Any ideas, someone had the same problems?
I would use something like MultiLog and see what is missing in log during app exit. That would give a pointer to what hangs.
https://wiki.lazarus.freepascal.org/MultiLog
-
In the case of Pascal (and many other languages such as C and C++), the "disadvantage" of calling ExitProcess in the application itself is that the language's RTL does not get a chance to do any cleanup of any internal resources it may be using. This is a "non problem" because whatever the RTL failed to cleanup, the O/S will clean up.
While cleaning up used resources usually isn't a problem, what can be a problem is if some things aren't flushed. Thus one should always cleanup nicely by oneself to make sure that everything that should be OS-side is OS-side. ;)