SIGSEGV error on exiting app in debugger

[jbmckim]

I've just started seeing this error.  The place where the code breaks is consistent (i.e. line 977).  Interestingly, I can break at line 978 and the break never hits.  Also, the program will error at 977 even if there's nothing actually on 977 (it's like a sick miracle).

No assembler box is displayed.

I'm curious as to how to go about tracking this down.

PS.  No error is thrown if I'm running the regular .exe outside the debugger.

[Martin_fr]

If you have the 64bit version of Lazarus and compile your app for 32bit, then check out this thread: https://forum.lazarus.freepascal.org/index.php/topic,47991.msg344926.html#msg344926

It is possible to debug 32bit apps in a 64bit IDE, but you need to follow the steps for the setup.

If the above is not your case, please supply the following info: https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Basic_Information

You can also try to download a newer gdb from our sourceforge page.
Select Win32 or Win64 (depending on if you installed the 32 or 64 bit IDE / you can run a 32 bit IDE on a 64 bit OS), an look for "alternative gdb"

[jbmckim]

First, maybe I'm missing something in your first part of your response but that link seems to want me to make sure you have a debugger hooked up to Laz.  From my post I hope its clear that the only problem my app is having is exiting while running under the debugger.  The debugger is gdb.exe.

Is the point of the second link to post a log that includes the error?

I've run heaptrc and there are no memory leaks.

Also, I misstated my first post in that where the code interrupts with an error at a given line, none of the lines in that routine execute.  That is, none of the breaks I posted in that procedure actually break.

Many paths through the code exit with an assembler interrupt that is thrown after the line of my code executes.  That is, after the last line of xxx.FormClose.

[trev]

It might help to tell us:

* operating system (I can only deduce from your reference to .exe it is Windows);
* operating system version and 32 bit/64 bit;
* Lazarus version and 32 bit/64 bit;
* FPC version;
* GDB version.

[Martin_fr]

First, maybe I'm missing something in your first part of your response but that link seems to want me to make sure you have a debugger hooked up to Laz.  From my post I hope its clear that the only problem my app is having is exiting while running under the debugger.  The debugger is gdb.exe.

Yes, it is clear you have gdb hooked up. But there are different ways that can be done. So the link asks to check.
But, unfortunately I was wrong in that other thread.

If your IDE is Win 64bit, then you can not debug a Win 32bit app.
The problem is fixed. But the fix is not in 2.0.x (I mistakenly though it was).
The fix is only in trunk/svn.

So if your are on Windows and your app is 32bit, you need the 32bit IDE.

There are other potential causes. But need more info to tell....

Is the point of the second link to post a log that includes the error?

Yes. And also for you to tell which OS you have....

For now I have only guessed that you are on Windows. You might be running Linux or MacOs, and the answers may be totally different.
I also only assumed, that your problem may be a 64bit IDE, debugging a 32bit app.

So please provide the info.

The log, will contain what happens in the IDE and gdb. There is no guarantee that it helps, but many times I was able to spot helpful details.
If you are concerned it reveals information that you do not want public, you can read it, and edit out details that you do not want public.

Also, I misstated my first post in that where the code interrupts with an error at a given line, none of the lines in that routine execute.  That is, none of the breaks I posted in that procedure actually break.

Many paths through the code exit with an assembler interrupt that is thrown after the line of my code executes.  That is, after the last line of xxx.FormClose.

If your breaks do not break and you end up in asm, then there may be an issue with debug info.
That might be a problem of its own, and might or might not be related to the SigSegv.

The log may again help to identify the issue.



As for potential fixes.....
- In Project options,  (you may already have those)
  - set debug info type to "dwarf with sets"
  - disable "smart linking"
  - disable "use external debug info"
  - disable "strip debug info"

- disable inlining.
  If you have the "inline" keyword in your code, then at the top of the unit insert "{$INLINE OFF}"

- try  https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#gdb.exe_has_stopped_working

- Tools => Options => debugger
  try different values for "internal start break" (this is a setting in the grid on the debugger option page)

I do not know if any of those will help. There are just wild guesses.

[jbmckim]

Good feedback all. 

OS:  Windows 10, build 18362.535
Laz version: 1.8
FPC version: 3.0.4

I'll chase up the log in the morning.  Thanks for the response.

[Martin_fr]

Laz version: 1.8

32 or 64 bit?

Any reason for the older version? Current is 2.0.6.
However 1.8 should be working too.

[jbmckim]

On the version question, this project was started awhile ago.  Development has been ongoing.  As it has not been necessary to update to newer versions I haven't.  Updating will, if possible and practical, be held off until the project is more or less complete.  That time is rapidly approaching though so the update will be happening in the coming months.

I'm running the 32 bit version of the IDE.  The target is currently 32 bit Debug.  Someplace during beta test or possibly before, Win64 release will be build and released.

[jbmckim]

Attached is the log.  Could be I've left a couple threads running?  Seems like that should be a hard kill when the program exists as they weren't spawned as standalone?

[Martin_fr]

I  edited /stroke out most of this. It appears that this is a subsequent error, only triggered by a previous issue.

----

Ok from the log.

Code: Text  [Select][+][-]

1. *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x0040dd7f",func="SYSTEM$_$TOBJECT_$__$$_FREE",args=[]},thread-id="1",stopped-threads="all"
2.  

This 99% likely means that you are double freeing an object.

You called "free" on an object that you already freed before.


The above  happens  right after

Code: Text  [Select][+][-]

1. =library-unloaded,id="C:\\WINDOWS\\SysWOW64\\sqlite3.dll",target-name="C:\\WINDOWS\\SysWOW64\\sqlite3.dll",host-name="C:\\WINDOWS\\SysWOW64\\sqlite3.dll",thread-group="i1"

That could be coincidence.

But it also could mean that the sqlite code (your code, or the package used) has an issue.

There is a stacktrace

Code: Text  [Select][+][-]

1. frame={level="0",addr="0x0040dd7f",func="SYSTEM$_$TOBJECT_$__$$_FREE"},
2. frame={level="1",addr="0x0066fc9d",func="MTPROCS_$$_finalize$",file="../../../../lazarus/components/multithreadprocs/mtprocs.pas",fullname="C:\\lazarus\\components\\multithreadprocs\\mtprocs.pas",line="869"},
3. frame={level="2",addr="0x0040fee1",func="SYSTEM_$$_FINALIZEUNITS"},
4. frame={level="3",addr="0x00410133",func="SYSTEM_$$_INTERNALEXIT"},
5. frame={level="4",addr="0x0040eb52",func="fpc_popaddrstack"}]
6.  

And that is in unit finalization.

"_INTERNALEXIT" could mean, that there was another, unreported error before this. So your app got a "halt", and while exiting crashes again.

[Martin_fr]

I just had a look into fpc_PopAddrStack (which is the lowest bit of that stack).
--- If that stack is correct ---

The only way to get that stacktrace is if an except handler was entered, without an exception. => that is the internal exception stack got screwed up.

That would likely be in your app, but very hard to track.
Open the stack window. It may show a few more lines.... (the log says there are 2 or 3 more lines, but not what they are)

So given that this happens in an "emergency halt", forget the double free. That is probably just the result of a previous error.



So from that there are a couple of possibilities.

The main question is... Did the error happen, Immediately when you start your app. With no user input, and before the app could do anything else?

If yes, then try the "internal start break" (set it to gdsbMain) I mentioned before.

Is your app build with a console ? -WC  or apptype console?

THere is a case, where the debugger can cause such a crash at startup.

The debugger interrupts the app early on, to do some work.
When that happens the OS creates a thread in your app (that otherwise would not exist). And if that happens a bit to early, then fpc's internal startup is not yet ready to handle the "thread created" notification it gets.

So if that happens at startup, before anything else, then this may be the case. InternalStartBreak should then deal with it (if needed try all avail values).


 

[jbmckim]

Sorry for the delay getting back but I've got other things going on as well.

I had a look at the log.  From that I'd have guessed that there might be an issue with _5NMArray but commenting it out makes no difference. In fact, check this:

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

1. C:\Users\Jeff\Documents\NVExitMon\colorunit.pas
2. colorunit.pas (1200,5) //_5nmArray : array of currency;
3. colorunit.pas (1214,15) //SetLength(_5nmArray,Length(ColorDat));
4. colorunit.pas (1216,27) //for i := 0 to (Length(_5nmArray) - 1) do
5. colorunit.pas (1217,8) //   _5nmArray[i] := ColorDat[i];

These are all the references to _5nmArray; I've triple checked the search criteria.  Note that they're all commented.  And yet, they're showing up in my debug dump.

This makes me suspect that there's maybe a binary or temporary working file that's not being overwritten at either compile, link or even debug runtime?

I tried the "Clean up and Build" in case it might know files that should be done away with properly.  (There is actually a function for this in Visual Studio, as left over files sometimes cause issues.)

Last item, your last post seems to deal with errors on debug start up.  I'm not seeing those.  The SIGSEGV is thrown on close.  Are you saying there could be an error on the load that could cause the close bug?  Just asking for sake of clarification.

[Martin_fr]

Last item, your last post seems to deal with errors on debug start up.  I'm not seeing those.  The SIGSEGV is thrown on close.  Are you saying there could be an error on the load that could cause the close bug?  Just asking for sake of clarification.

Under very specific conditions, an app could fail to start in the debugger.  (At least on windows)
That is, it would crash (and only crash in the debugger), within the first few milliseconds. Before opening any window, and before writing anything to console.

That can be fixed with the InternalStartBreak option.
(In Lazarus trunk, the page is called "debugger backend".)

Does not seem to apply to you though

If your app fails at a later time, then the problem may be something else.

Have you tried if the "Stack Window" shows anything?

From the part of the stackframe, that I extracted (see my other post).

It shows _INTERNALEXIT => show the error happens in a "finalize" block of one of your units.

What is free'd in mtprocs in the finalization section (end of file)?