Help tracing a sigsev fault on applicatin exit.

[Josh]

Hi
I have a strange problem, when I close my application I am getting a sigsev error, (Laz and FPC latest SVN) using Win 32 version.
I have put breakpoint at various locations; one in the main form onclose event at the end, and also one in the lpr at the end.
Debugger stops at these, I continue and it get to he final end in the lpr file and at this point no sigsev;
So the sigsev is occuring after the final application end.

My app does have a tthread; however in the close event i terminate the thread; and check that the thread has actually terminated.

How can I get information of what is happening and causing a problem after this?

ANyone with any help how to track down an issue; it's probably something i have done.

[Girlbrush]

You might be a bit too diligent about freeing things. Components with a parent will get freed as the parent does. If you free it yourself, that can cause odd issues like that.

[ChrisF]

One of the other possibilities is that you (eventually) update directly (i.e. without Synchronize) an LCL control inside your thread. In this case, the program may crash when exiting, and not when you update the control (I've experimented it by myself, silly me).

[Eugene Loza]

I agree with Girlbrush, I've experienced the same issue for a generic list.
You should free your classes only once (except when you know what you are doing) - you shouldn't manually free classes that are freed automatically.
You might also want to create and turn on DEBUG mode (in Project Options), sometimes (but not always) it helps a lot to track such stuff.

and check that the thread has actually terminated.

You might also have FreeOnTerminate = true, and then try to access fields of already-destroyed thread class instance.

[balazsszekely]

My app does have a tthread; however in the close event i terminate the thread; and check that the thread has actually terminated.

Don't do that. It can lead to deadlock, especially if you update the GUI via the synchronize method. This issue was discussed many times before, please do a forum search.

[Josh]

Hi All,

Thanks for responding.

I have just done a test where I do not start the thread at all, and I still get the sigsev when I close app.

I have a global variable called MyThread_has_Finished; which is set to true on the very last line of the thread.execute section, this is the variable that was being checked to confirm the thread has finished running.

Any classes I have declared and used in local procedure are not freed; as these will be freed automatically, any classes I have used globally are also not freed, I have just gone through the code and commented out all .free statements just to double check; yet I am still getting a sigsev error on close.

The code I am using to shut down thread is

Code: [Select]

  Terminate_Thread:=True;  // Global variable used in thread to orderly shutdown remaining data etc, whilst waiting for thread to shutdown;
  .....
 
  // Update app config files for screen position etc
  .......
  // close any open hardware devices
  ........
  // this section takes a minimum of 250 ms to complete
  // each iteration of thread loop takes less than 1ms; so thread should be safe to shutdown as anything will have been finished.
  ....
  if MyThread <> nil then  // check if thread is still there
  begin
    MyThread.Terminate;
    MyThread.WaitFor;
  end;             
  if Thread_has_Terminated then showmessage('Thread Successfully terminated') else showmessage('Thread has not terminated');// this shows terminated message
  If I run the app on MAC I do not get this sigsev error; only difference is use of cthreads and cmem on mac.

Another strange occurance is that on windows I have a memo that has visible set to false; yet it still displays; when I update the memo I also add some text to give me visibilty state; on each occurence it says memo1.visible = false; yet I can see the memo; on MAC i cannot see the memo.  SO something odd is happening. First thought was memory leak, but if i check for mem leak on OSX I do not have any, but I cannot see if the same code is causing a mem leak due to the sigsev error on app close.

[Mr.Madguy]

In most cases it happens due to freeing something, that should be freed elsewhere, when program terminates. If you don't do it, then it's worst and most tricky case, programmer could possibly encounter - heap corruption. Heap corruption is tricky, just because AV happens not when heap is actually being corrupted, but much later - at any arbitrary moment, when this object is being used. Also heap corruption - is floating bug. It may stay unnoticed on your computer, but appear on another. For example when I develop my programs, 32bit version may work correctly, but 64bit may throw "Invalid pointer operation" faults. Worst case of heap corruption, I've ever encountered - is when call to some GDI API, like GetWindowRect, in one part of the program was causing AV in hal.dll in completely different part of program, that wasn't directly connected with this one. Some memory managers, like FastMM, can track heap corruptions, if they happen with your heap - not heaps of some other dlls. In some cases heap corruption isn't obvious and can be tracked only via using asm debugging, cuz sometimes heap corruptions happen due to so called "compiler magic". But in most cases best method - is to notice recent changes in code, that caused this error, and try revert them. And of course - to write safe code.

P.S. Do you use dlls? At least in Delphi passing strings to dll without using ShareMem causes heap corruption.

[Leledumbo]

Rebuild RTL with debug info and recompile, you should be able to get it the exact location where the SIGSEGV occurs.

[Thaddy]

if MyThread <> nil then .... really? Do you mean if Assigned(MyThread), maybe? Different things. In a multi-threaded environment both are not necessarily true at the same time. So the heap manager won't know. And can cause a SIGSEV.

[Josh]

Hi

To eliminate my thread; I have removed the whole thread from the application, and I am still getting the error on close; so it's not the thread.

i will have to dig a bit deeper into the code of other components.

@thaddy thanks for the info; I have changed it to Assigned(Mythread) but this has made no difference; so removed mythread completely.

Also I have still got a visible memo; that is actually not visible; so I think I will completely remove lazarus trunk and start a fresh with new installation.
It would be good to try latest 1.6.5 fixes but as proj is created with 1.7svn it has additional properties on the form and additional ones in the tpanel; that stops it opening in 1.6.5

when i compiled rtl with debug it stopped here. lclclasses

Code: [Select]

destructor TLCLComponent.Destroy;
begin
  {$IFNDEF DisableChecks}
  if FLCLRefCount>0 then
    DebugLn(['WARNING: ' + ClassName + '.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?']);
  {$ENDIF}
  {$IFDEF DebugLCLComponents}
  //DebugLn('TLCLComponent.Destroy ',DbgSName(Self));
  DebugLCLComponents.MarkDestroyed(Self);
  {$ENDIF}
  inherited Destroy;   <-------------
end;       

I have checked my code and made sure that I have not destroyed any components that I have created; and made sure that all components belong to the form.

Will report back when I have completed a total fresh install with latest svn...

[Thaddy]

Maybe you can use fcl-async?

[Josh]

Hi
Well just finished installing a fresh SVN, took some time slow internet speed here... takes a few hours.

I have just commented out the routines that generate controls in runtime; and still the same, so will leave it for a bit and do some thinking, might end up removing vast chunks of application to help narrow down the problem.

[Bart]

if MyThread <> nil then .... really? Do you mean if Assigned(MyThread), maybe? Different things.

Are you sure?
"if assigned(p)" seems to give the same assembler output as "if p<nil"

Code: [Select]

# [5] if assigned(p) then
cmpl $0,U_$P$TEST_$$_P
jne .Lj3
jmp .Lj4
.Lj3:

and

Code: [Select]

# [5] if p<>nil then
cmpl $0,U_$P$TEST_$$_P
jne .Lj3
jmp .Lj4
.Lj3:

Bart

[Mr.Madguy]

when i compiled rtl with debug it stopped here. lclclasses

Code: [Select]

destructor TLCLComponent.Destroy;
begin
  {$IFNDEF DisableChecks}
  if FLCLRefCount>0 then
    DebugLn(['WARNING: ' + ClassName + '.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?']);
  {$ENDIF}
  {$IFDEF DebugLCLComponents}
  //DebugLn('TLCLComponent.Destroy ',DbgSName(Self));
  DebugLCLComponents.MarkDestroyed(Self);
  {$ENDIF}
  inherited Destroy;   <-------------
end;       


Stack trace should suggest you, what component is failing. Still strange place for AV, cuz if inherited method call itself fails, then vmt can be corrupted.

[JuhaManninen]

Are you sure?
"if assigned(p)" seems to give the same assembler output as "if p<nil"

Yes, my understanding also is that they do the same thing.
Neither syntax however knows if the pointer is valid or if it contains garbage. They only compare the value against Nil.