SIGSEGV error

[egsuh]

What could be a problem?
SIGSEGV error occurs, when I "close" a form of an application within Lazarus IDE, but no problem when it's run (and closed) from .exe file.
I do nothing but opening a form, and then close it.
 

[Thaddy]

So?
Give us a minimal project as usual.....

[Martin_fr]

That is an "empty form", exactly the way you get it, if you do project -> new project -> application? (and run as it is / empty)

If yes, see below.

If NO: provide an example (and ignore below)

And only if run in the IDE? Assuming that means under the debugger...
Though you might simple not notice the sigsegv, outside the debugger should it happen while closing the app.

Under Windows:
I have seen such errors, caused by 3rd party products (any other software on your computer) which registers shell-handlers (windows explorer - handler for certain file types), or install system wide dll (like antivirus may do). Those dll may behave different under gdb, and they may be loaded with your app, even if you do not use them.

That leads to the question: Which OS? (and 32/64bit?)

Exact version of Lazarus, FPC and gdb?

If it is only under the debugger, create a log: http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

[egsuh]

I'm using Lazarus 1.8.4.

This error does not happen when I run it on Windows 7 / 64 bit.

I copied the files to my 32 bit (Windows 8 and Windows 10) machine, and then the problem happens.
During the 'copying' process (I used briefcase), there was a warning saying that the attributes of some files have been changed --- possibly project.lps file. I checked the attribute of project.lps file, but cannot find any peculiar thing.

With empty projects, no problem.

The project contains little bit many unit files, so I'll try to find the reason by myself a little more, and if I can reproduce the problem with smaller project, then I'll post it.

[kegge13]

As preparation of porting a large project to FPC I set up a minimal project in Lazarus v2.0.0.RC3 r59877 on a W7/64 platform
It also happens when I close the application: True heap size: 229376; True free heap: 229216 (a difference of 160), then it raises the SIGSEGV error and comes with the debug window as shown in the image (att.).

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

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ExtCtrls, ComCtrls,
9.   Menus;
10.  
11. type
12.  
13. TForm1 = class(TForm)
14.     ApplicationProperties: TApplicationProperties;
15.     MainMenu: TMainMenu;
16.     FileMenu: TMenuItem;
17.     PageControl1: TPageControl;
18.     StatusBar: TStatusBar;
19.     TabSheet1: TTabSheet;
20.     procedure FormCreate(Sender: TObject);
21.   private
22.   public
23.     procedure SetStatus(AString:String);
24.   end;
25.  
26. var
27.   Form1: TForm1;
28.  
29. implementation
30.  
31. {$R *.lfm}
32.  
33. uses StrUtils;
34.  
35. { TForm1 }
36.  
37. procedure TForm1.FormCreate(Sender: TObject);
38. begin
39.   Form1.Caption:= ReverseString('Hello World!');
40.   with TabSheet1 do Caption:= ReverseString(Caption);
41.   with FileMenu do Caption:= ReverseString(Caption);
42.   SetStatus(ReverseString('Every thing reversed for some reason'));
43. end;
44.  
45.  
46. procedure TForm1.SetStatus(AString:String);
47. begin
48.   StatusBar.Panels[0].Text:= AString;
49. end;
50.  
51. end.                  
52.  

I have set the compiler options to "debug".
As I intend to make a project with a lot of objects and structures being opened and closed, having a reliable heap check is highly appreciated.
Many thanks for a response.

[howardpc]

Most likely you forgot to add any panels to your statusbar, so StatusBar.Panels[0] is Nil.

[kegge13]

I added a statuspanel to the the statusbar; see procedure SetStatusbar.
The SIGSEGV error really came out of the blue. I tried to remove the statusbar completely with no result at all. Also commented out all instructions in FromCreate with no result at all.

[kegge13]

Now I started from really scratch. Just created a project with an empty form, created debug mode in the options and compiled. Again at the identical address,
0000000077002B04 ff4024                   incl   0x24(%rax), the SIGSEGV error is raised (when I close the form). Again the difference is 160 bytes between True heap size and True free heap.

[howardpc]

Your SetStatusBar method adds no panels to the Panels collection.
It assumes Panels[0] exists.
You must either create a panel in code, or add one in the Object Inspector (or use the SimplePanel property).

[kegge13]

I had added a panel. ... and as posted above I can get the SIGSEGV error with an empty form too!

[howardpc]

Can you zip the offending project and post it here?

[jamie]

So assuming you did this

StatusBar.Panels.add;

 Then
StatusBar.Panels[  StatusBar.Panels.Count-1 ].Text := 'My Text will work!';

should add to the list...

[kegge13]

I took the file from my office home, and ran it at my desktop with the same result. Then I installed Lazarus on the W7/64 laptop and recompiled with the same result. But now there is a little bit more information: the 160 bytes are coming from "System Startup". Due to size limitations I had to strip the .exe and .dbg from the project for upload here.
The very same error can be demonstrated with just an empty form running!

Thanks a lot for your suggestions. A flawless memory check means a lot to me.

[jamie]

Its telling you that it's used in startup, does not mean it still is hanging around.

 I don't know if you have placed this status bar on the form via the OI, if you didn't, then you
need to create the whole thing at startup.

 But I am going to assume for the moment that you did do it in the OI and you should of added some
panels there if you didn't do it at runtime.

[howardpc]

a "flawless memory check" is the

0 unfreed memory blocks : 0
Heap statistics are dependent on your operating system and setup.

For instance, for your project compiled on my linux machine I see
596 memory blocks allocated and freed
and
true heap size/free heap identical at 131072
These heap statistics tell you little of importance since they are hardware and OS dependent.