GExperts supports even more laziness

[Mahdi Safsafi 225]

13 minutes ago, dummzeuch said:

I managed to fix the problem with Delphi 2005. It was totally unrelated: Some code when loading the code formatter configuration raised an external exception C000001D ((Illegal Instruction) for an inlined function when optimization was enabled. In the process I added the same exception handling to the editor experts that was already in place for regular experts, so now one faulty editor expert can no longer prevent all others from being loaded and initialized. Also the user gets a better error message in that case.

Very good. Just wondering does this behavior occur only on D2005? Or all older versions too? 

[dummzeuch 1505]

1 hour ago, Mahdi Safsafi said:

Very good. Just wondering does this behavior occur only on D2005? Or all older versions too? 

This particular problem was Delphi 2005 specific.

 

It resulted in an error message on every start of the IDE, when the GExperts DLL was compiled with optimization on. That's why I never encountered it in my tests before, because all my test builds are compiled with optimization turned off. I don't remember why I changed that this time. Maybe I just forgot to uncheck that option. Delphi 2005 did not have separate configurations for Release and Debug builds, that came with Delphi 2007.

 

As for older versions: Those did not support the inline keyword.

Edited July 19, 2020 by dummzeuch

[Mahdi Safsafi 225]

1 hour ago, dummzeuch said:

As for older versions: Those did not support the inline keyword.

Almost forget that information. Thanks. 

[Stefan Glienke 2007]

I am really missing a "don't bother me at all about any exception during the current debug session" button.

[Mahdi Safsafi 225]

7 minutes ago, Stefan Glienke said:

I am really missing a "don't bother me at all about any exception during the current debug session" button.

Filtering is based on regex ... does using '.*' counts ?  

Edited July 19, 2020 by Mahdi Safsafi

[Stefan Glienke 2007]

1 minute ago, Mahdi Safsafi said:

Filtering is based on regex ... does using '.*' counts ?  

The filters work on Exception class name and that does not support regex or does a sub type check

[Mahdi Safsafi 225]

2 minutes ago, Stefan Glienke said:

The filters work on Exception class name and that does not support regex or does a sub type check

Yeah I missed that. 

[dummzeuch 1505]

9 hours ago, Stefan Glienke said:

The filters work on Exception class name and that does not support regex or does a sub type check

Subclass checks would be very difficult to implement because all the expert knows is the exception name and the message. I know of no way to query the class inheritance in that context. But a regex for the name would be possible.

[Stefan Glienke 2007]

Probably possible using the debugger evaluation or something but being able to have an "any" option in the exception class field would be enough - and probably a button "ignore any" in the exception dialog.

Currently I am solving this by setting a non breaking breakpoint at the start of the unit tests with "ignore subsequent exceptions" but I forget to set that up often enough.

[Lars Fosdal 1792]

I'd like

"Disable break on exception this thread" 

"Disable break on exception in other threads" - limiting the breaks to the current thread or threads spawned in the current thread.

[Guest]

11 minutes ago, Lars Fosdal said:

"Disable break on exception this thread" 

"Disable break on exception in other threads" - limiting the breaks to the current thread or threads spawned in the current thread.

That is neat and pretty useful.

[dummzeuch 1505]

2 hours ago, Lars Fosdal said:

I'd like

"Disable break on exception this thread" 

"Disable break on exception in other threads" - limiting the breaks to the current thread or threads spawned in the current thread.

If you have got a suggestion on how that could be implemented, I'll give it a try. So far I don't see a way to get information about the thread in which the exception has been raised.

[Lars Fosdal 1792]

14 hours ago, dummzeuch said:

If you have got a suggestion on how that could be implemented, I'll give it a try. So far I don't see a way to get information about the thread in which the exception has been raised.

TBH, I am not sure that can be implemented without either digging into the debugger or using techniques like those in EurekaLog where it appears they inject their own exception class that is thread aware?
 

It was more of a wish list for the debugger team, than for GExperts.

[dummzeuch 1505]

16 minutes ago, Lars Fosdal said:

It was more of a wish list for the debugger team, than for GExperts.

In that case: Did you file a feature request with Embarcadero? I'm sure I'm not the only one who would vote on it.

[Lars Fosdal 1792]

I will do that.

[Guest]

Looking at IOTAProcess60 in OpenToolsApi and wondering if this can solve this, may be the logical thing for GetCurrentThread to return the thread raised the exception and a break issued on it, but why it is IUnkown ?

  IOTAProcess60 = interface(IUnknown)
    ['{34B2E2D2-E36F-11D1-AB0E-00C04FB16FB3}']
    { Adds an IOTAProcessNotifier }
    function AddNotifier(const Notifier: IOTAProcessNotifier): Integer;
    { Return the currently active thread }
    function GetCurrentThread: IOTAThread;
    { Return the number of Thread in this process }
    function GetThreadCount: Integer;
    { Return the index'd Thread }
    function GetThread(Index: Integer): IOTAThread;
    { Get the debugger's internal process ID }
    function GetProcessId: LongWord;
    { Stop/Pause the process }
    procedure Pause;
    { Read the process memory at the given address }
    function ReadProcessMemory(Address: LongWord; Count: Integer; var Buffer): Integer;
    { Removes the index'd IOTAProcessNotifier }
    procedure RemoveNotifier(Index: Integer);
    { Run the process with the specified run mode }
    procedure Run(RunMode: TOTARunMode);
    { Set a new current thread }
    procedure SetCurrentThread(Value: IOTAThread);
    { Reset/Terminate the process }
    procedure Terminate;
    { Write to the process memory at the given address }
    function WriteProcessMemory(Address: LongWord; Count: Integer; var Buffer): Integer;

    property CurrentThread: IOTAThread read GetCurrentThread write SetCurrentThread;
    property ProcessId: LongWord read GetProcessId;
    property ThreadCount: Integer read GetThreadCount;
    property Threads[Index: Integer]: IOTAThread read GetThread;
  end;

There is also IOTAProcessNotifier90 

  IOTAProcessNotifier90 = interface(IOTAProcessNotifier)
    ['{E2725B23-E67C-4CF1-B928-FA0F5B9C2C29}']
    { Called after a process' current thread is changed }
    procedure CurrentThreadChanged(const Thread: IOTAThread);
    { Called when a process' thread list changes.  This notification is purposely
      vague.  Things like thread creation, thread destruction, thread attribute
      changes (for now just thread name) are reported via this notification }
    procedure ThreadListChanged(const Process: IOTAProcess);
  end;

@dummzeuch Have you checked them?

[dummzeuch 1505]

From the description I gather that I would have to implement IOTAProcessNotifier90 and hope that CurrentThreadChanged is called often

and timely enough to provide the information on time. Might be worth a try.

[Stefan Glienke 2007]

You probably have to use an IOTADebuggerNotifier to detect ProcessCreated/ProcessDestroyed - there you have to add/remove IOTAProcessNotifier and get ThreadCreated/ThreadDestroyed and you can already guess it add/remove an IOTAThreadNotifier which has ThreadNotify where you are interested in TOTANotifyReason.nrException. The corresponding IOTAThread instance has all the required information like the OSThreadID or Handle properties

[Guest]

3 hours ago, Stefan Glienke said:

there you have to add/remove IOTAProcessNotifier and get ThreadCreated/ThreadDestroyed and you can already guess it add/remove an IOTAThreadNotifier which has ThreadNotify where you are interested in TOTANotifyReason.nrException.

I think that part is not needed, once IOTAProcess is acquired then 

function GetCurrentThread: IOTAThread;

should return the current one in this case ( i mean break point on exception).

as you suggested IOTAThread90 does have 

property OSThreadID: LongWord read GetOSThreadID;

and this should do it .

 

The point is i don't think keep tracking/notified of all threads is necessary.

[Stefan Glienke 2007]

I was not sure what "current" means in the context of being called from the IDE from the hooked "break because of exception" method - but you could be right - that would make it easier.

[Guest]

I think this should clear that

[dummzeuch 1505]

1 hour ago, Kas Ob. said:

I think this should clear that

I'm definitely a bit slow today. I can't make out what the screenshot is supposed to tell me.

[dummzeuch 1505]

By popular request of a single gentleman (*) there is now a button "Ignore All this Session".

 

 

The exception class name is now also a regex. Empty matches any exception.

 

(* I'm not sure this really carries the meaning of the German joke "Auf vielfachen Wunsch eines einzelnen Herrn ..." )

[Guest]

15 minutes ago, dummzeuch said:

I can't make out what the screenshot is supposed to tell me.

That was to clear the point Stefan pointed if Current is a thread in the debugged process or belongs to the debugger itself.

Screenshot shows how internally TProcess::GetCurrentThread is returning IOTAThread (same TGUID) which does have Evaluate means it belongs to the debugged process.

 

Now, how to use that, you already have in TBaseDebuggerNotifier 

ProcessCreated 

ProcessDestroyed

This is already solved this thing, i mean getting the IOTAProcess and save it.

all what is left i think, is to use IOTAProcess60.GetCurrentThread to get IOTAThread50.GetOSThreadID

 

I tried to get access to FBaseDebuggerNotifier from GX_FilterExceptionsNotification , but i don't see an easy or elegant way to do it without butchering your code, you design it you can redesign it.

 

 

Before click submit, i tried for last time and it is working !!

 

with such code just for testing , and it is ugly, there should be a better approach than global function, but that is up to you.

Function GetCurrentThread:TThreadID; // in unit GX_FilterExceptions
begin
  if Assigned(GlobalDebuggerNotifier) then
    begin
      result  := IOTAProcess60(GlobalDebuggerNotifier.GetCurrentProcess).CurrentThread.OSThreadID;
    end;
end;

  TBaseDebuggerNotifier = class(TNotifierObject, IOTADebuggerNotifier)
  private
    FNotifierIndex: Integer;
    FProcess: IOTAProcess;
  public
    constructor Create;
....
	Function GetCurrentProcess: IOTAProcess;
	end;
    
constructor TBaseDebuggerNotifier.Create;
begin
  inherited;
  FProcess := nil;
end;

procedure TBaseDebuggerNotifier.ProcessCreated({$IFDEF GX_VER170_up} const {$ENDIF} Process: IOTAProcess);
begin
  FProcess := Process;
end;

procedure TBaseDebuggerNotifier.ProcessDestroyed({$IFDEF GX_VER170_up} const {$ENDIF} Process: IOTAProcess);
begin
  FProcess := nil;
end;

function TBaseDebuggerNotifier.GetCurrentProcess: IOTAProcess;
begin
  Result := FProcess;
end;

and the result

[Mahdi Safsafi 225]

@dummzeuch I made some debugging and was able to get much more information about the exception. On the attached file you will find a lot of useful stuff plus some comment for clarification.  

I hope, you will find it useful for GExperts.

ExceptionFilter.pas