Recent

Author Topic: Detect sigsegv  (Read 4440 times)

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Detect sigsegv
« on: March 22, 2018, 06:51:17 pm »
Hi, I'm using GDB on Windows, and yes, in project options the -g option is on, and most debugging options are on also, I usually get error lines, but when I close the application it gets an external sigsegv and I can't find where.

Is only displayed when I compile in Debug, when compiled in Release it does not show.

I know it's related to something like trying to access a memory location that is not available, like accessing an object that is already destroyed when the form is closed.

But I can't find it on a big project without the line number... Sorry, I'm not so experienced debugging.

Any ideas of what I can do?

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: Detect sigsegv
« Reply #1 on: March 22, 2018, 07:39:26 pm »
To me sounds like a GDB sigsegv not your application. Build in debug mode and then "Run with out debugging" does it steel raise the exception on exit? if not then the problem is in gdb not your application.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Detect sigsegv
« Reply #2 on: March 22, 2018, 07:48:54 pm »
To me sounds like a GDB sigsegv not your application. Build in debug mode and then "Run with out debugging" does it steel raise the exception on exit? if not then the problem is in gdb not your application.

Thanks. Yes, as you said there is no sigsegv when running without debugging.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Detect sigsegv
« Reply #3 on: March 22, 2018, 07:54:42 pm »
Try "DisableLoadSo..." or similar in the property grid of the global debugger options.

Sometimes libraries crash under gdb, though that is more likely during start than stop of the app.

Do you get an asm window on the exception?
Also stack? I assume stack end after 1 or 2 entries?

If so then either the execution jumped into nowhere land, or the crash is in a library or kernel.

-----------
Try compiling all packages with debug info (use "Additions and overrides"

That still leaves you with fpc/rtl having no debug info.

-----------
Do you use heaptrc (-gh) ?
If so, did you try heaptrc outside the debugger?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Detect sigsegv
« Reply #4 on: March 22, 2018, 07:55:42 pm »
if gdb crashed, you do not get an asm window.
If your app crashed you do get an asm window (or stack, even if unreadable)

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Detect sigsegv
« Reply #5 on: March 22, 2018, 08:38:52 pm »
if gdb crashed, you do not get an asm window.
If your app crashed you do get an asm window (or stack, even if unreadable)

I get the assembler window, but is all filled with zeroes.

I will check all the other settings you mentioned.

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Detect sigsegv
« Reply #6 on: March 22, 2018, 09:10:05 pm »
Hi again,

Try "DisableLoadSo..." or similar in the property grid of the global debugger options.

I did that. And it shows the error the same.


Do you get an asm window on the exception?
Also stack? I assume stack end after 1 or 2 entries?

Is like this:

Code: Pascal  [Select][+][-]
  1. 00000000 ??????

All repeated in the entire window.


Try compiling all packages with debug info (use "Additions and overrides"

That still leaves you with fpc/rtl having no debug info.

Ok. I will try. We're using some third party stuff from Online Package Manager, 3 packages if I'm not wrong.

I need to do with all packages, there is an easy way to switch for all of them?


Do you use heaptrc (-gh) ?
If so, did you try heaptrc outside the debugger?

Yes, and there is no memory leak outside the debugger.

But is a good point, there is no memory leak window when I close when debugging.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Detect sigsegv
« Reply #7 on: March 22, 2018, 09:43:13 pm »
Ok stack like this is weird.

I would expect a diff error if gdb had stopped, but I am not sure.
Yet all 0000 is not what should happen...

Can you run a logfile please:
http://wiki.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

It can contain symbolnames and stdout/err of your app, so make sure it has nothing private, if you are worried.

Attach the log

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Detect sigsegv
« Reply #8 on: March 23, 2018, 12:05:03 am »
Ok, I will do it tomorrow.

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Detect sigsegv
« Reply #9 on: March 23, 2018, 02:01:52 pm »
Hi again, here is attached the log.

Seems that there is a problem with Rx component? rxlookup.pas and other rx .pas files are mentioned.

And here is the 00000000 address:

Code: Pascal  [Select][+][-]
  1. TCmdLineDebugger.ReadLn "*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x00000000",func="??",args=[]},thread-id="1",stopped-threads="all""

Code: Pascal  [Select][+][-]
  1. TCmdLineDebugger.ReadLn "^done,threads=[{id="8",target-id="Thread 7620.0x3094",frame={level="0",addr="0x7773e7ac",func="??",args=[],from="C:\\WINDOWS\\SYSTEM32\\ntdll.dll"},state="stopped"},{id="7",target-id="Thread 7620.0x20" ..(946).. "x10a8",frame={level="0",addr="0x00000000",func="??",args=[]},state="stopped"}],current-thread-id="1""

Code: Pascal  [Select][+][-]
  1. TCmdLineDebugger.ReadLn "^done,stack=[frame={level="0",addr="0x00000000",func="??"},frame={level="1",addr="0x004b0ecb",func="EXECSQL3",file="globales.pas",fullname="C:\\Users\\Damian\\Documents\\Proyectos\\posberry\\globales." ..(464).. "clude/customform.inc",fullname="C:\\fpcupdeluxe\\lazarus\\lcl\\include\\customform.inc",line="976"}]"

This line in customform is
Code: Pascal  [Select][+][-]
  1. if Assigned(FOnDestroy) then FOnDestroy(Self);
« Last Edit: March 23, 2018, 02:14:11 pm by lainz »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Detect sigsegv
« Reply #10 on: March 23, 2018, 03:53:39 pm »
Code: [Select]
Well at least something. By the look of the logfile the stackwindow should also show the information (the top entry will be 0x0000000, but the other should be there / btw in case of unexpected stack, check the threads window too; threads can be created by dll)

[codl]^done,stack=[
frame={level="0",addr="0x00000000",func="??"},
frame={level="1",addr="0x004b0ecb",func="EXECSQL3",file="globales.pas",fullname="C:\\Users\\Damian\\Documents\\Proyectos\\posberry\\globales." ..

Instead of customform, you should check globales.pas. (and several inbetween).

globales.pas calls some function at address 0x0000000 and that of course crashes.

If the stack window for some reason does not show globales.pas (even if you switch threads) then there is some really bad bug in the IDE somewhere (on top of the bug in your app). Menu > View >Debug Windows > Debug Output (you should open the window before the crash happens) ... has the full result of the gdb stack command, so you can get the line there.

Thaddy

  • Hero Member
  • *****
  • Posts: 14159
  • Probably until I exterminate Putin.
Re: Detect sigsegv
« Reply #11 on: March 23, 2018, 06:22:11 pm »
Martin... You have made my day. Tnx.
Only one remark: use assert
Specialize a type, not a var.

lainz

  • Hero Member
  • *****
  • Posts: 4449
    • https://lainz.github.io/
Re: Detect sigsegv
« Reply #12 on: March 23, 2018, 06:41:52 pm »
Instead of customform, you should check globales.pas. (and several inbetween).

globales.pas calls some function at address 0x0000000 and that of course crashes.

If the stack window for some reason does not show globales.pas (even if you switch threads) then there is some really bad bug in the IDE somewhere (on top of the bug in your app). Menu > View >Debug Windows > Debug Output (you should open the window before the crash happens) ... has the full result of the gdb stack command, so you can get the line there.

Thanks. I found the problem was calling a method in FormDestroy, the method is as you said in globales.pas. Seems that sqlite is not available in that stage. I don't know if is that exactly but the problem is fixed.

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: Detect sigsegv
« Reply #13 on: March 24, 2018, 04:02:51 am »
sounds like a managed exception to me was it that important to track down?
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

Thaddy

  • Hero Member
  • *****
  • Posts: 14159
  • Probably until I exterminate Putin.
Re: Detect sigsegv
« Reply #14 on: March 24, 2018, 09:34:46 am »
sounds like a managed exception to me was it that important to track down?
Of course. More specific since it was a SEGSEV. Exceptions are exceptional, managed or not.
Not fixing it is the hallmark of a very very lousy programmer. If you KNOW an exception can occur beforehand you should fix it.
Managed Exceptions are for the cases where you do NOT know beforehand.

You are not a lousy programmer, but in this case not fixing it is equivalent to this coding style:
Code: Pascal  [Select][+][-]
  1. function failme:Boolean;
  2. begin
  3.   try
  4.     result := false;
  5.   except
  6.     result := true;
  7.   end;
  8. end;
  8-) 8-) 8-) 8-) %)

And this happens all the time......
« Last Edit: March 24, 2018, 10:21:55 am by Thaddy »
Specialize a type, not a var.

 

TinyPortal © 2005-2018