Segfault at the very end of the program

[TCH]

Thank you for your efforts and advices.

Unfortunately it seems, it is not the buttonlist what causes the problem. I removed all of the .Free-s from my code (which means the buttons and toggles are lost after the array rearrangement, but at the end, the form will free them), but the crash at the end persists.

Lead by a sudden idea, i took my old version of this program, what uses Lazarus's built-in TTabControl. (I wrote my own class, because TTabControl lacked the close button per tab.) And it still crashes at the exit. Which means, the crash is not caused by my tabbar.

And the error is always appears after the CLASSES$_$TPERSISTENT_$__$$_FPONOTIFYOBSERVERS$TOBJECT$TFPOBSERVEDOPERATION$POINTER label in the assembly source.

At this point, the tabbar has been ruled out, the threads has been ruled out... I simply don't understand why this error happens.

Maybe the dynamically created Memos and Images can do this? Can i create arrays of widgets from the editor?

[howardpc]

Without access to the error-producing code it is not possible to say with certainty. Speculation gets us only so far.
Can you make a savagely cut-down version of your program with dummy data, omitting most of the functionality that still shows the problem (one that could be shared and debugged by others)?

[TCH]

Sorry, but i had no idea what caused the problem, so cutting out pieces would cause the error being gone. However, it seems i've found the problem. I added the following piece of code to TForm1.FormClose

Code: Pascal  [Select][+][-]

1.      for i := 0 to 19 do
2.      begin
3.           infotx[i].Free;
4.           infoimg[i].Free;
5.      end;

and the crash at the end is gone...

It seems to me, that Lazarus is actually does not frees the dynamically created and assigned elements at all when closing the application. I even put back the threads and all seems ok.

[howardpc]

Glad you finally nailed it.
Usually such code is placed in the form's OnDestroy handler (not the OnClose).

[TCH]

Thanks for your efforts. Still it's a bit strange to me. Now, is Lazarus supposed to destroy the dynamically assigned objects, or it is the programmer's task?

[howardpc]

Dynamically created means you created the instances via code you wrote (instance:=TSomething.Create;).
So it's your responsibility to free those instances when no longer needed.
If the instances are components, you can transfer responsibility for ultimate destruction to an Owner, but otherwise it is up to you, or they will never be freed and give a memory leak.
It's good practice always to develop with the heaptrc option checked in the debugging page of your Project Options. That way you get immediate feedback if there are objects you've forgotten to free, and can correct it before the program grows too big and complex.

[Handoko]

I saw from:
http://forum.lazarus.freepascal.org/index.php/topic,38768.msg264459.html#msg264459

The code has:

Code: Pascal  [Select][+][-]

1. infotx[i] := TMemo.Create(Form1);
2. infoimg[i] := TImage.Create(Form1);

Both of them have owner. But why we still need to free them manually?

[munair]

Especially when creating object arrays you have to be careful as you may have to free objects by looping through all array elements.

Remember my reply #20? I marked it with red in the quote. Glad you found it. 

[TCH]

@howardpc:
Yeah, i understand it, but i was told, if i set an owner to them, then the owener will handle their destroying.
Thanks for the heaptrc tip, i've checked it on. But where it will warn me? In the Messages window, or it will throw a popup window?

@Handoko:
Yes, this what i don't get too.

@Munair:
You were right. Unfortunately i missed the point, that the Memos and Images are also dynamically created and i was only focusing on the buttonlist.

[howardpc]

I think you're developing on Linux, so View->Debug windows->Terminal Output will show the output from heaptrc.

Code: Pascal  [Select][+][-]

1. infoimg[i]:=TImage.Create(Form1);

is all the ownership you need, provided infoimg[ i ] is not freed or recreated anywhere else.

Maybe try Application as the Owner, rather than Form1, just in case the images outlive the Form1 instance (since you use threads, there may be the possibility that instance lifetimes are not fully synchronised with the main thread)?

[TCH]

That was all i did...

I see, it's reporting in the "Console", thanks. It tells me, i have 0 unfreed memory blocks, so it's all ok, my program finished leaking. Well, thanks for the tip, i'll try to set Application as the owner, but not now, right now, i'm glad that this is fixed finally.

[taazz]

I saw from:
http://forum.lazarus.freepascal.org/index.php/topic,38768.msg264459.html#msg264459

The code has:

Code: Pascal  [Select][+][-]

1. infotx[i] := TMemo.Create(Form1);
2. infoimg[i] := TImage.Create(Form1);

Both of them have owner. But why we still need to free them manually?

You actually do not have to free them manually. Well only if you want to replace them before Form1 is destroyed and reclaim their memory otherwise let the form1 to do its job. The only thing that would require a manual destruction is a bug in the lcl it self or if the variable form1 points to an invalid instance, after all form1 is a variable made by the IDE and can have a number of values. But my guess is that the code written by the user does not take in to account the state of the object and it tries to access already destroyed or in the process of destroying controls and the thing blows up. By moving the destruction to an earlier moment in the chain he inevitably changed the balance and allowed the code to work. That does not mean that the bug was found it only means that he is a step closer to find it.

[TCH]

Before this, the infoimg and infotx objects were no destroyed at anywhere in the program, so i could not access it after or meanwhile it's destroyed.

[taazz]

Before this, the infoimg and infotx objects were no destroyed at anywhere in the program, so i could not access it after or meanwhile it's destroyed.

so they are not accessed during destruction how about the controls in the arrays accessing others?

[TCH]

Controls in the arrays accessing others? I don't understand.

Edit: Argh, it seems you may be right. I encountered another segfault at tab changing and i found where it happens: when i clear the images in the main thread. For test, i commented out that line and while this segfault disappeared, the crash at the exit returned...

Edit 2: And even more strange, if i turn the "heaptrc" option on, then all the segfaults are gone! And it reports back, that i have no unfreed memory blocks...