Incomplete stack trace on manually created bug report 64-bit

delphi package - automated exception handling
Post Reply
thall
Posts: 3
Joined: Fri Aug 14, 2020 3:52 pm

Incomplete stack trace on manually created bug report 64-bit

Post by thall »

Hi madshi,

We are updating a Delphi Web Server to 64-bit and have come across an issue with how we use madExcept. We have a trigger in the application to manually generate a bug report that we can use to debug problems (e.g. a deadlocked thread), we trigger the bug report using code similar to this:

Code: Select all

procedure TForm1.Button1Click(Sender: TObject);
var
  Report: string;
  Exc: IMEException;
begin
  Exc := NewException(etNormal);
  Exc.ShowPleaseWaitBox := false;
  Report := Exc.GetBugReport;

  AutoSaveBugReport(Report); // save without UI
end;
In 32-bit this works fine, however in 64-bit the thread that triggers the report does not correctly generate the stack trace. e.g. if you use the above code on a standard vcl app, the main thread stack trace looks like:

Code: Select all

thread $3a94:
00000000 ???
and the cpu registers, stack dump and disassembling sections are missing.

Is there a better way to generate a bug report on demand, or is this a bug in the 64-bit support? Using the default behaviour of madExcept to catch exceptions that reach the global handler is working absolutely fine in 64-bit.

We are using Delphi Rio 10.3.3 and MadExcept 5.0 (2.8.8.0), although I did try the latest release and the same problem occurs.

Many thanks for your help,
Tony
madshi
Site Admin
Posts: 10365
Joined: Sun Mar 21, 2004 5:25 pm

Re: Incomplete stack trace on manually created bug report 64

Post by madshi »

There's an ugly workaround you can use:

Code: Select all

  try
    raise Exception.Create('manual bug report');
  except
    Report := CreateBugReport(etNormal);
  end;
Hope that helps?
thall
Posts: 3
Joined: Fri Aug 14, 2020 3:52 pm

Re: Incomplete stack trace on manually created bug report 64

Post by thall »

Hi madshi,

That did indeed work in my test app, however it didn't work in the real application, I was still getting a single line stack trace for the thread that threw the exception (full stacks for other threads). After some further experimenting I found that your new code worked correctly if the MadExcept setting 'HandleExceptions' was enabled, but didn't if it was disabled.

I had assumed that 'HandleExceptions' setting determined whether to hook MadExcept into the global exception handler, and because we were manually creating the bug report this setting would make no difference (as seems to be the case in 32-bit). From what I can see this setting is only used in the patching process, so I'm not too sure why it would affect the stack trace generation. Also I noticed if I created the report using etFrozen I also got a full stack trace for the thread that threw the exception (although that thread is no longer first in the list). Can you explain exactly what the 'HandleExceptions' setting does and if it is a requirement for generating bug reports manually?

Thanks,
Tony
madshi
Site Admin
Posts: 10365
Joined: Sun Mar 21, 2004 5:25 pm

Re: Incomplete stack trace on manually created bug report 64

Post by madshi »

Hmmmm... In 64bit madExcept relies on some internal hooks to make some things work, and these hooks are only installed if Handle Exceptions is activated. I've not tested any madExcept functionality with "Handle Exceptions" disabled. Maybe you could make it work by passing ExceptObject and ExceptAddress to the CreateBugReport function as parameters?
thall
Posts: 3
Joined: Fri Aug 14, 2020 3:52 pm

Re: Incomplete stack trace on manually created bug report 64

Post by thall »

Thanks madshi! We ended up enabling HandleExceptions and using your suggested code. All is working well now.
Post Reply