Debugger problems (after first run)
lazarus / 12-Debugger

----------------------------------------------------------------------
Marius · 2007-11-23 12:59

Windows, Laz 0.9.25Beta (SVN)/Fpc2.2.1/mingw.gdb6.6

When I start lazarus and debug a simple program it works perfect and i
can run or debug it without any problems, the program run's and exits
without any problems (perfect!).

However if i start debugging the program for the second time (without
resetting the debugger) the debugger reports 3  exceptions (procedure
muldiv) and a SIGSEGV exception.

I noticed that this only happends when the gdb.exe stay's open in the
background (only after a reset debugger and gdb.exe disappears its
working again). I can report this as a bug, but i'm unsure how to
describe this bug. Is it normal that de gdb.exe stay's open in the
background or should it be closed after the debugged program exits?

(this was the actually the reason for Ctrl-F2 on "Reset debugger"
menu)

----------------------------------------------------------------------
Marc · 2007-11-23 13:35

iirc it had something to do with having a mainfest for you app with
one, the debugger crashes after the first time

----------------------------------------------------------------------
Marius · 2007-11-23 15:15

Sorry, i dont really understand what you're saying or what it implies.
Do i need to create a manifest for a brand new application?


Or should i call "EndDebugging" (somewhere?) as a quickfix for the
time being?

----------------------------------------------------------------------
Marc · 2007-11-26 10:34

No, what I mean that it is a known error that the debugger crashes on
applications which have a manifest.
If the application has a manifest, depends if you checked "use
manifest" in your project options. (manifest -> XP look)

----------------------------------------------------------------------
Marius · 2007-11-26 12:58

Ah that way.. I have never noticed that checkbox, is alway's
unchecked, standard project options.

----------------------------------------------------------------------
Marc · 2007-11-26 13:37

ok, then debugging should normally work.
After your first debugging session, what is the output in the view-
debugger-debuggeroutput ?
 (and what's added there when you start the second time)

----------------------------------------------------------------------
Marius · 2007-11-26 14:32

I created a new project, only overruled the tform constuctor and set a
breakpoint on the hello world. First time its debugs perfect, second
time it crashes as described. Debugger output in the next message..

unit DbgCrashUnit;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs;

type

  { TForm1 }

  TForm1 = class(TForm)
  private
    AString: string;
  public
    constructor Create(AOwner: TComponent); override;
  end;

var
  Form1: TForm1;

implementation

{ TForm1 }

constructor TForm1.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  AString := 'hello world';
end;

initialization
  {$I DbgCrashUnit.lrs}

end.

----------------------------------------------------------------------
Marius · 2007-11-26 14:34

And this is the debugger output from the second run only:

<-file-exec-and-symbols "O:/Applications/DbgCrash/DbgCrash.exe">
^done

(gdb)

<-gdb-set language pascal>
^done

(gdb)

<-environment-cd "O:/Applications/DbgCrash/">
^done

(gdb)

<-data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC>
^done,value="0x0"

(gdb)

<-exec-arguments >
^done

(gdb)

<-gdb-set language pascal>
^done

(gdb)

<info address main>
&"info address main\n"

~"\n"

~"   Symbol \"main\" is a function at address 0x4025c0.\n"

^done

(gdb)

<-break-insert -t *4203968>
^done,bkpt={number="6",type="breakpoint",disp="del",enabled="y",addr="
0x004025c0",func="main",file="DbgCrash.lpr",fullname="O:\\Applications
\\DbgCrash/DbgCrash.lpr",line="13",times="0"}

(gdb)

<-break-insert FPC_RAISEEXCEPTION>
^done,bkpt={number="7",type="breakpoint",disp="keep",enabled="y",addr=
"0x00409b46",func="fpc_raiseexception",file="except.inc",line="189",ti
mes="0"}

(gdb)

<-break-insert FPC_BREAK_ERROR>
^done,bkpt={number="8",type="breakpoint",disp="keep",enabled="y",addr=
"0x0040afc0",func="HANDLEERRORADDRFRAME",file="system.inc",line="840",
times="0"}

(gdb)

<-break-insert FPC_RUNERROR>
^done,bkpt={number="9",type="breakpoint",disp="keep",enabled="y",addr=
"0x0040b0a3",func="RUNERROR",file="system.inc",line="883",times="0"}

(gdb)

<info file>
&"info file\n"

~"Symbols from \"O:/Applications/DbgCrash/DbgCrash.exe\".\n"

~"Local exec file:\n"

~"\t`O:/Applications/DbgCrash/DbgCrash.exe', file type pei-i386.\n"

~"\tEntry point: 0x4db4c0\n"

~"\t0x00401000 - 0x004db4e0 is .text\n"

~"\t0x004dc000 - 0x0051c9e8 is .data\n"

~"\t0x0051d000 - 0x00531890 is .bss\n"

~"\t0x00532000 - 0x00534540 is .idata\n"

^done

(gdb)

<-exec-run>
^running

(gdb)

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

*stopped,reason="signal-received",signal-name="SIGTRAP",signal-
meaning="Trace/breakpoint trap",thread-id="1",frame={addr="0x7c57b74c"
,func="MulDiv",args=[],from="C:\\WINNT\\system32\\KERNEL32.DLL"}

(gdb)

<-stack-info-depth>
^done,depth="1"

(gdb)

<-stack-list-arguments 1 0 0>
^done,stack-args=[frame={level="0",args=[]}]

(gdb)

<-stack-list-frames 0 0>
^done,stack=[frame={level="0",addr="0x7c57b74c",func="MulDiv",from="C:
\\WINNT\\system32\\KERNEL32.DLL"}]

(gdb)

<info program>
&"info program\n"

~"\tUsing the running image of child thread 572.0x3b8.\n"

~"Program stopped at 0x7c57b74c.\n"

~"It stopped with signal SIGTRAP, Trace/breakpoint trap.\n"

~"Type \"info stack\" or \"info registers\" for more information.\n"

^done

(gdb)

<-break-insert LmsLogForm.pas:56>
&"No source file named LmsLogForm.pas.\n"

^done

(gdb)

<-break-insert DbgCrashUnit.pas:31>
^done,bkpt={number="10",type="breakpoint",disp="keep",enabled="y",addr
="0x0041abb7",func="TFORM1__CREATE",file="DbgCrashUnit.pas",fullname="
O:\\Applications\\DbgCrash/DbgCrashUnit.pas",line="31",times="0"}

(gdb)

<-break-enable 10>
^done

(gdb)

<-exec-continue>
^running

(gdb)

~"error return win32-nat.c:1442 was 6\n"

~"error return win32-nat.c:1442 was 6\n"

*stopped,reason="signal-received",signal-name="SIGTRAP",signal-
meaning="Trace/breakpoint trap",thread-id="1",frame={addr="0x7c57b74c"
,func="MulDiv",args=[],from="C:\\WINNT\\system32\\KERNEL32.DLL"}

(gdb)

<-stack-info-depth>
^done,depth="1"

(gdb)

<-stack-list-arguments 1 0 0>
^done,stack-args=[frame={level="0",args=[]}]

(gdb)

<-stack-list-frames 0 0>
^done,stack=[frame={level="0",addr="0x7c57b74c",func="MulDiv",from="C:
\\WINNT\\system32\\KERNEL32.DLL"}]

(gdb)

<-stack-list-frames 0 0>
^done,stack=[frame={level="0",addr="0x7c57b74c",func="MulDiv",from="C:
\\WINNT\\system32\\KERNEL32.DLL"}]

(gdb)

----------------------------------------------------------------------
Marc · 2007-11-27 10:23

?????
What kind of windows is this ?

I've never seen the "error return win32-nat.c:1442 was 6" messages,
these are from gdb iirc.
What worries me is the breakpoint on MulDiv. Somehow windows jumps
into a breakpoint, and that is usuallty not a good thing.

----------------------------------------------------------------------
Marius · 2007-11-27 17:41

This happends under windows 2000 service pack 3 i believe (at work).
Nothing special with that version, in fact i just reinstalled it three
weeks ago.
(http://www.smiley-channel.de/grafiken/smiley/technik/smiley-
channel.de_technik014.gif)

At home i have windows xp and there the same program works ok

----------------------------------------------------------------------
Marc · 2007-11-28 10:56

I test on a VM with SP4

however I wonder what MulDiv will report if a 0 is passed

----------------------------------------------------------------------
Martin_fr · 2008-02-28 17:57

I also get the
~"error return win32-nat.c:1442 was 6\n"

but with a different line number. And it effectivley stops me from re-
ussing the debugger (I have to reset it, between each two debug
sessions).

It always does happen with:
GNU gdb 6.7.50.20071127

with the GDB delivered with Laz 0.9.24: "GDB 6.6" it does happen only
sometimes. Not sure about the exact conditions.

From the view hits I found on google, it appears that GDB does not
release all thread handles properly.

This link is from 2005, I would expect it to be applied, but never one
knows:
http://sourceware.org/ml/gdb-patches/2005-03/msg00241.html