mahdisafsafi / debugengine Goto Github PK

Test in Delphi 11 alexandria, and both in 64 and 32 bits the line number does not appear for Stack Trace or when an exception occurs

unit DebugEngine.Trace;

procedure TCallTrace32.RemoveSealedCalls; can raise an AV in sub function TargetExists if PItem^.Info.ProcedureAddress is nil then (PPointer(PItem^.Info.ProcedureAddress)^ = Address) raises an AV

I suggest the following change in order for fixing it : change function TStackItem.IsValid: Boolean; to the following implementation:

function TStackItem.IsValid: Boolean;
begin
Result := (Rank <> 0) and (Info.ProcedureAddress <> nil);
end;

The final statement in TTDebugInfoExport.CreateExportList is

FExportList.Sort(ExportFunctionsSortCompare);

Is it necessary?
Would it be possible to provide a Sort property that determines whether to sort or not?

I've already added the necessary code, and would be happy to make a pull request.

Please add support for Microsoft debugging information in a ".dbg" file.

I could not compile with XE3 because of the two occurences of FinalizeRecord in DebugEngine.DebugInfo (Line 1672) and DebugEngine.Disasm (Line 606).

I fixed it with
PExportInfo(FExportList[I])^ := Default(TExportInfo); // DebugEngine.DebugInfo Line 1672
and
DisasmInfo := Default(TDisasmInfo); // DebugEngine.Disasm Line 606

As I don't know, in which Version of Delphi FinalizeRecord arrived and how you would resolve it (ifdef or something else) I commit no pull request.

Insert debug info does'nt work on release builds. I've tried both the DD tool and the ConvertMapToSMap function in the project. It fails on both 32 and 64 bit.

How to reproduce:

1. Build the demo as release.
2. press "Insert debug info" button.

Or use the DD tool

1. Build the demo as release.
2. Call the DD tool: dd -c "./Win64/Release/ExceptionTest.map"

Hi,

unit DebugEngine.Trace on line 1860

      if IsBadCodePtr(P) then
        Break;

if you compile code in x86, IsBadCodePtr function gets accessviolation.
How can I solve this issue?

Best regards.

Hello

I belive there is a bug in ConvertMapToSMap, atleast it raises an exception parsing a certain map file, and that leads to an endless loop.

I've attatched a small demo application reproducing the exception.

I've made a small modification to the DebugEngine.DebugInfo unit. I've introduced a global variable called DebugCount. It's jous used for counting iterations.

But in short. Set a breakpoint in line 1083 in my version of DebugEngine.DebugInfo. Run the application and press the button.

The code can be found here: http://borrisholt.dk/GitHub/ExceptionTest.7z

Jens Borrisholt

Most developers agree that in applications given to the wide public map information (method names, line numbers, etc) must not be included. Stack trace should contain addresses only which can be translated "back" to readable names by the developer with the .map file in place.
My question is, does DebugEngine support this behavior? Can it work without the .map file attached to the executable, and can it somehow be forced to "load" a .map file and look up an address and translate it to names and line numbers?

If yes, is there a guide which I can read on this topic?

Thanks!

السلام عليكم.

الرجاء توجيه لتشغيله في "delphi 7".
Please guide me to compile and run in "delphi 7 32 bit".

Using Delphi berlin free.
if not IsBadCodePtr(Pointer(Arg.Imm.Value)) then
On DebugEngine.Disasm;
Getting access violation.!!!!!
Cannot debug since i do not have the source.
With out the Delphi IDE the exe run OK.

Line 1974: J := NativeUInt(PFrame^.CallerFrame) - NativeUInt(PFrame);

if NativeUInt(PFrame^.CallerFrame) > NativeUInt(PFrame) then you get an AV since you are casting to NativeUInt.

In DebugEngineDemo.dpr in uses is file "DebugEngine.ThreadUtils" but not exists in repository

Using Delphi 10.2 Version 25.0.27659.1188
Using provided demo, compiling with debug configuration, changing compiler options to enable overflow checking and range checking, an EintOverflow is produced in TDebugInfoSMap.ProcessMap on the line:
Result^.SegStartAddress := Pointer((PSegment^.SegStartAddress - LModuleImageBase) + Module.ModuleHandle);
Actually SegStartAddress is 0 and both LModuleImageBase and ModuleHandle have same value ($400000).

In DebugEngine.Core, perhaps correctly

...
procedure GetDelphiExceptionHandlersPtr(var Info: THandlersPtr);
asm
  {$IFDEF CPU64BITS }
  mov  rax,  offset System.@DelphiExceptionHandler
  mov  qword [rcx].THandlersPtr.SEHandler ,              rax
  { Fill all the rest with nil }
  xor rax,rax
  mov qword  [rcx].THandlersPtr.HandleFinallyPtr,        rax
  mov qword  [rcx].THandlersPtr.HandleAnyExceptionPtr,   rax
  mov qword  [rcx].THandlersPtr.HandleOnExceptionPtr,    rax
  mov qword  [rcx].THandlersPtr.HandleAutoException,     rax
  {$ELSE CPU64BITS }
  mov dword  [eax].THandlersPtr.SEHandler,               $00000000
  mov dword  [eax].THandlersPtr.HandleFinallyPtr,        offset System.@HandleFinally
  mov dword  [eax].THandlersPtr.HandleAnyExceptionPtr,   offset System.@HandleAnyException
  mov dword  [eax].THandlersPtr.HandleOnExceptionPtr,    offset System.@HandleOnException
  mov dword  [eax].THandlersPtr.HandleAutoException,     offset System.@HandleAutoException
  {$ENDIF CPU64BITS}
end;

yy

When using Delphi 10.2 Version 25.0.27659.1188, 32 bits debug configuration, there are very annoying exceptions triggered in DecodeBranch_Ev on the line "AM_32: P := PByte(PUInt32(P)^);".

They are ignored by a try/except but this make DebugEngine almost unusable in a real project while debugging. The exception pops up while working as soon as a stack trace is build.

Instead of capturing the exception with try/except, it should be avoided.

By the way, the exceptions I saw where triggered because the address (Variable P in the code) fall in the first KB of memory which is a protected area. A simple test would avoid the exception.