View Issue Details

IDProjectCategoryView StatusLast Update
0011950LazarusDebuggerpublic2010-05-22 14:11
ReporterVladimir Zhirov Assigned ToMarc Weustink  
Status closedResolutionno change required 
Product Version0.9.25 (SVN) 
Target Version1.0.0 
Summary0011950: SIGSEGV when debugging non-LCL applications
DescriptionIf I debug LCL application created with "File -> New -> Application", everything works as expected. However when I try to debug non-LCL application (e.g. console application, custom application or fpGUI one), the debugger works every second try and I get two error message boxes when I start debugging:

1) "Project raised exception class 'External: SIGSEGV'."

2) "Execution paused
Adress: $7C918FEA"
Procedure: ntdll!RtlpWaitForCriticalSection
(Some day an assembler window might popup here :)"

Exception address and procedure stay the same for all non-LCL projects I tried to debug.

The whole process looks like this:
- Run (F9)
- Error message 0000001, pressing "OK"
- Error message 0000002, pressing "OK"
- Application console appears, the output is empty
- Application hangs
- Stop (Ctrl-F2)
- Run (F9)
- Error message 0000001, pressing "OK"
- Error message 0000002, pressing "OK"
- Application console appears
- The output appears in console, or fpGUI window appears on the screen
- Application is running, and debugger is working as expected until the application is terminated.

Then I have to start from the beginning to get the debugger working.

Some background info:
* Windows XP.
* Lazarus 0.9.25 r16153. I was able to reproduce it a month ago too, I cannot remember the revision number though.
* I have -g and -gl options enabled in "Project -> Compiler Options -> Linking". -XX, -CX and -Xs options are disabled.
* fpc 2.2.2 (shipped with Lazarus).
* gdb (shipped with Lazarus).
* Path to gdb contains no spaces or non-ASCII characters.
TagsNo tags attached.
Fixed in Revision
Attached Files


related to 0017089 closedMartin Friebe Can not debug a non-LCL application without including unit Interfaces 


Vladimir Zhirov

2008-08-29 10:54

reporter   ~0021770

Possible workaround is to include LCL as a dependency for any project (even non-LCL one) and put 'Interfaces' unit in program uses clause.

Vincent Snijders

2008-11-10 14:08

manager   ~0023287

Can you test with snapshots of 11 November and later, which contain gdb version 6.8-3?

Vladimir Zhirov

2008-11-16 10:05

reporter   ~0023388

Yes, I will test.
Should I test with 0.9.27 snapshot, or fixes contain new version of gdb too?

Vincent Snijders

2008-11-16 10:27

manager   ~0023390

Both should have it.

Vladimir Zhirov

2008-11-19 06:37

reporter   ~0023428

The problem persists with new gdb. The behavior is exactly the same.

Paul Ishenin

2009-03-06 05:00

manager   ~0025949

Please retest once again with more recent 0.9.27 version. I cannot reproduce it. Maybe it somehow related to few debugger issues we already fixed after your last note.

Vladimir Zhirov

2009-03-06 14:45

reporter   ~0025958

Tested, the problem is still here.

Paul Ishenin

2009-03-06 15:44

manager   ~0025959

Then maybe you will attach your application wich cause the problem?

Vladimir Zhirov

2009-03-10 22:15

reporter   ~0026034

I can reproduce it with a simple "hello world" console program:

program project1;
{$mode objfpc}{$H+}
  Classes, SysUtils;
  Writeln('Hello World');

Paul Ishenin

2009-03-10 23:58

manager   ~0026036

and where is {$apptype console} ?

Vladimir Zhirov

2009-03-11 18:39

reporter   ~0026059

According to page 32 of FPC programmers manual (prog.pdf) CONSOLE is the default application type, there is no need to set it explicitly.

I've just noticed though the behavior has changed, I'm sorry for not mentioning it earlier. If the debugger is enabled programs without dependency on LCL does not work at all now, even on the second try. They always hang after showing 'External: SIGSEGV' message and assembler window. So the example application never shows 'Hello world' if run in the debugging mode. LCL-dependant programs that have interfaces.pp in their uses clause work as expected.

Paul Ishenin

2009-03-12 02:32

manager   ~0026063

I cannot reproduce any problem. Try to update your fpc to recent 2.3.1 and check with it. But really I dont know where and how to search for that problem.

Vladimir Zhirov

2009-03-13 08:31

reporter   ~0026079

Well, this problem is not critical for me because of the workaround mentioned in the first note. Switching to fpc 2.3.1 is not desirable for me at the moment because of the existing projects I must keep stable. It is OK for me if the problem could be only solved by new fpc or dgb release. Maybe we should change the severity of this issue to minor or even close it.

Paul Ishenin

2009-03-13 09:00

manager   ~0026082

And what gdb version do you use? Can you test with gdb 6.8? Can you run your program under gdb without IDE?

Vincent Snijders

2009-03-13 09:01

manager   ~0026083

I cannot reproduce this with my lazarus executable compiled on 8-3-2009 and fpc 2.2.2.

Vladimir Zhirov

2009-03-13 18:36

reporter   ~0026093

Last edited: 2009-03-13 18:42


GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
This GDB was configured as "i686-pc-mingw32"...
(gdb) start
Breakpoint 1 at 0x4014ae: file project1.pas, line 10.
Starting program: D:\work\exp\testdbg/project1.exe
[New thread 1836.0x4ec]

Program received signal SIGSEGV, Segmentation fault.
0x7c918fea in ntdll!RtlpWaitForCriticalSection ()
   from C:\WINDOWS\system32\ntdll.dll
(gdb) step
Single stepping until exit from function ntdll!RtlpWaitForCriticalSection,
which has no line number information.
0x7c90eaf0 in ntdll!LdrDisableThreadCalloutsForDll ()
   from C:\WINDOWS\system32\ntdll.dll

The same program compiled with LCL dependency works as expected both in Lazarus and when debugging via the command-line gdb.


If both Paul and you cannot reproduce it, maybe it is hardware related problem. I think the CPU is the first thing to check, I tested it on Intel Pentium 4 Willamette 1500 MHz Stepping D0.

Vladimir Zhirov

2010-05-19 22:25

reporter   ~0037800

The problem seems to be caused by COMODO Internet Security proactive defense. Cannot reproduce it anymore after I disabled proactive defense module.
It is also reported to work ok with latest version of COMODO (4.0).

Would somebody please resolve this issue with "no change required"?

Issue History

Date Modified Username Field Change
2008-08-23 15:21 Vladimir Zhirov New Issue
2008-08-23 15:21 Vladimir Zhirov Status new => assigned
2008-08-23 15:21 Vladimir Zhirov Assigned To => Marc Weustink
2008-08-23 15:21 Vladimir Zhirov Widgetset => Win32
2008-08-29 10:54 Vladimir Zhirov Note Added: 0021770
2008-11-10 14:08 Vincent Snijders LazTarget => 1.0
2008-11-10 14:08 Vincent Snijders Note Added: 0023287
2008-11-10 14:08 Vincent Snijders Status assigned => feedback
2008-11-10 14:08 Vincent Snijders Target Version => 1.0.0
2008-11-16 10:05 Vladimir Zhirov Note Added: 0023388
2008-11-16 10:27 Vincent Snijders Note Added: 0023390
2008-11-19 06:37 Vladimir Zhirov Note Added: 0023428
2008-11-19 06:49 Vincent Snijders Status feedback => assigned
2009-03-06 05:00 Paul Ishenin Note Added: 0025949
2009-03-06 05:00 Paul Ishenin Status assigned => feedback
2009-03-06 14:45 Vladimir Zhirov Note Added: 0025958
2009-03-06 15:44 Paul Ishenin Note Added: 0025959
2009-03-10 22:15 Vladimir Zhirov Note Added: 0026034
2009-03-10 23:58 Paul Ishenin Note Added: 0026036
2009-03-11 18:39 Vladimir Zhirov Note Added: 0026059
2009-03-12 02:32 Paul Ishenin Note Added: 0026063
2009-03-13 08:31 Vladimir Zhirov Note Added: 0026079
2009-03-13 09:00 Paul Ishenin Note Added: 0026082
2009-03-13 09:01 Vincent Snijders Note Added: 0026083
2009-03-13 18:36 Vladimir Zhirov Note Added: 0026093
2009-03-13 18:42 Vladimir Zhirov Note Edited: 0026093
2010-05-19 22:25 Vladimir Zhirov Note Added: 0037800
2010-05-19 22:39 Vincent Snijders Status feedback => resolved
2010-05-19 22:39 Vincent Snijders Resolution open => no change required
2010-05-22 14:11 Vladimir Zhirov Status resolved => closed
2010-08-03 00:02 Vincent Snijders Relationship added related to 0017089