# TCastleView.Stop called from FINALIZATION section
**URL:** https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526
**Category:** Uncategorized
**Created:** [February 8, 2025, 11:56am UTC](https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526 "2025-02-08T11:56:46Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@NiunioMartinez](https://forum.castle-engine.io/u/NiunioMartinez)
#### Post date: [February 8, 2025, 11:56am UTC](https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526/1 "2025-02-08T11:56:46Z")
I had a really weird SIGSEGV in my project and I wasn’t able to understand why as I were cleaning and _nulling_ everything correctly. In a long GDB session I’ve found that view’s `Stop` method is called from a `finalization` section! That conflicts my cleaning because I’m using a global object I create in `initalization` and free in `finalization` that is initialized in the view’s `Start` method and finalized in the view’s `Stop` method.
I’m aware my design isn’t the best (it’s an ugly _hack_ just for testing) but anyway I think that view’s `Stop` method _shouldn’t_ be called after program termination. Why isn’t it called from `TApplication.Terminate`? Why is it delayed to the `finalization` section?
This is like `TForm`’s event `OnDestroy`: It is guaranteed that it’s called before the program finished.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [February 8, 2025, 1:47pm UTC](https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526/2 "2025-02-08T13:47:29Z")
> [@NiunioMartinez](#):
>
> This is like `TForm`’s event `OnDestroy`: It is guaranteed that it’s called before the program finished.
On the contrary, you can test. Running the attached example shows that _after_ the main `begin .. end.` ends, the form gets `OnHide` and `OnDestroy` events.
[terminate\_finalization.zip](https://forum.castle-engine.io/uploads/short-url/pznQAsmR0iMjd0FBLE3NFRF5K4a.zip) (140.7 KB)
What happens and why:
`Application.Terminate` merely sets a flag to terminate as soon as possible. This is true both for `Application` singleton used by LCL (from LCL `Forms` unit) and for `Application` singleton from `CastleWindow` unit.
When using `CastleWindow`: the `finalization` section of `CastleWindow` actually stops any view (old name: “UI state”) we were in, then frees window and application.
When using LCL it is similar, the `finalization` section of `Forms` does `FreeThenNil(Application)`.
The above behavior is standard. LCL applications (unrelated to CGE) also behave lke this.
Why?
- We cannot stop and free things right when `Application.Terminate` is called, as it’s often called from callbacks/methods of a form/view. Freeing everything from `Application.Terminate` would require extra-careful usage of `Application.Terminate`.
- The main program, of both LCL application and CGE application, doesn’t have any other explicit call to “free everything now”. LCL depends on `finalization` of `Forms`. CGE depends on `finalization` of `CastleWindow`.
Solutions in your case:
1. You can make your `Stop` method “resilient” to the fact that it’s called from `finalization`. If it accesses something else, that may be already freed at this point, then check is it `nil` before.
2. Alternatively: you can get the behavior you want by modifying the auto-generated CGE program file, `xxx_standalone.dpr`. By default it’s really trivial:
3. Alternatively: you can add the `Application.MainWindow.Container.View := nil;` call before you free your global object. I understand you have a line like this right now:
---
### Author:  [@NiunioMartinez](https://forum.castle-engine.io/u/NiunioMartinez)
#### Post date: [February 8, 2025, 7:06pm UTC](https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526/3 "2025-02-08T19:06:44Z")
Then I misunderstood it.
I take note of the ways to fix it. I think 3. will be my favourite.
---
### Author:  [@edj](https://forum.castle-engine.io/u/edj)
#### Post date: [May 10, 2025, 1:52pm UTC](https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526/4 "2025-05-10T13:52:06Z")
You probably have this figured out by now but I had the same issue. I found using Application.MainWindow.CloseQuery was a good way to intercept app shutdown before the finalizations. I am in agreement that finalizations are a dangerous place to clean up since order is arbitrary.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [May 10, 2025, 6:26pm UTC](https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526/5 "2025-05-10T18:26:53Z")
> [@edj](#):
>
> I found using Application.MainWindow.CloseQuery was a good way to intercept app shutdown before the finalizations.
I will just add that I still don’t recommend `OnCloseQuery` for this purpose, for reasons explained in comment in [Where to intercept closing application? - #3 by michalis](https://forum.castle-engine.io/t/where-to-intercept-closing-application/1897/3) 🙂 I know it works in your project, but in general
- `OnCloseQuery` is a way to “ask for confirmation before closing form (e.g. to save some document)”, not “a place to do cleanup”.
- `Stop` is a place to do cleanup, and if you want `Stop` of your view to happen before some `finalization`, then use `Application.MainWindow.Container.View := nil` , as shown in this thread (point 3 above, which I understand the OP followed) or [Where to intercept closing application? - #3 by michalis](https://forum.castle-engine.io/t/where-to-intercept-closing-application/1897/3) .
---
### Author:  [@edj](https://forum.castle-engine.io/u/edj)
#### Post date: [May 11, 2025, 2:02pm UTC](https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526/6 "2025-05-11T14:02:15Z")
I suffered crashes on close for years. Spent so long trying to figure out. Even crashes closing the vanilla client/server demo when data is flowing. Now they are all solved. Maybe if you used threads more, you would realize the danger of doing too much in finalization. This solved it all…
```auto
procedure TViewMain.StopServerAndExit;
begin
ShowNotification( 'Stop water flow threads.' );
StopWaterFlowThreads;
StopServer;
Application.MainWindow.Close;
end;
procedure TViewMain.CloseQuery(AContainer: TCastleContainer);
begin
StopServerAndExit;
end;
```
I feel kinda stupid for not managing to realize until a couple days ago that stop was being called from finalization! I got too rusty using other languages (which all suck). Best to clean up your own garbage haha.
If there was something like an OnBeforeClose callback, that would be ideal to get the threads shutdown before finalizations. In the meantime CloseQuery is that callback. I can’t just check nils as the the threads walk multiple arrays of 100,000+ singles doing constant addition at 60+ tiles/second to insure the objects don’t get deleted out from under it. In the VCL world they offered something like that but memory fails. I am happy with how things work now, you don’t need to do add anything.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [May 12, 2025, 4:40pm UTC](https://forum.castle-engine.io/t/tcastleview-stop-called-from-finalization-section/1526/7 "2025-05-12T16:40:05Z")
> [@edj](#):
>
> Maybe if you used threads more, you would realize the danger of doing too much in finalization.
Doing things in `OnCloseQuery` is executing them in the same thread as you would as in `finalization`. I don’t think you achieve anything by doing things in `OnCloseQuery` versus in “`finalization` after making sure that views have stopped by `Application.MainWindow.Container.View := nil`”.
And since `OnCloseQuery` is _not_ going to run always when window is closed by explicit `Window.Close` ( [Where to intercept closing application? - #3 by michalis](https://forum.castle-engine.io/t/where-to-intercept-closing-application/1897/3) ), it’s still not the best place to make “cleanup that must be executed always” 🙂
I realize that things are difficult when using threads, and client/server, but this doesn’t change the above recommendation.
- If you have threads, you must cleanup the data correctly.
- If you client/server in threads, you may need to also wait for those threads.
- I realize it’s not easy (and why Indy can make either memory leaks or crashes, as documented in [3.4. Note: There are known memory leaks when using Indy](https://castle-engine.io/multi_player#_note_there_are_known_memory_leaks_when_using_indy)).
- Still, if you want to make a “cleanup that always executes”, doing it in `Stop` of the view is what I recommend. This is our equivalent of `OnBeforeClose` callback that you mention.