We have been able to trace a problem that had been driving us crazy for quite a while back to madExcept.
Problems were being reported by many customers, and oddly enough no exception logs were available.
All the problems involved inter process communication.
Our App is built with Delphi but we use an ever growing amount of .net plugins. We use Hydra from RemObjects for communication between the delphi host and the .net plugins.
The problem is that in very special conditions when handling an exception madExcept will remain in an endless loop. The madExcept error report pops up and reports 'callstack will be calculated' soon.
Hitting the 'End program' or 'Restart program' buttons has no effect and the process must be killed.
Hitting the 'Continue' button makes the dialog go away but code is no longer executed and the process must be killed.
I have found a very specific set of steps, which lead to a 100% reproducible case. This error happens always.
What is very odd is that if I do comparable steps with other parts of the program, the problem does not ocurr.
Now what is so special/different/unique about that specific part of the code/program?
After spending a LOT of time on this I was not able to identify anything that stands out about this part of the code.
My goal was to be able to create a sample project for you so you can more easily troubleshoot the issue.
So I fear this will not be possible.
But there are some better news following.
Here is what I do know.
A .net plugin receives a TCP message from another process.
The .net plugin uses Hydra to call some Delphi code on the Delphi host app.
An exception is thrown while the Delphi code is executing. As a test I am raising an exception as soon as the delphi code is executed.
madExcept handles the exception and gets stuck in an infinite loop while trying to obtain the callstack.
Strangely, not all TCP messages cause this problem. It is only with specific messages that the problem happens.
But it can be reproduced 100% reliably if following the 'proper' steps.
The problem only happens if the .net plugin is compiled in release mode. Callstack is obtained just fine when compiling the .net plugin in debug mode.
Problem happens only with 64 bit.
Since I was getting nowhere in trying to create a sample project for you. I decided to add the madExcept source files to our project instead of using the bpl's.
I defined debugMadExcept and I was then able to debug the madExcept code.
What I found is that an endless loop is ocurring during CollectPossibleStackItems inside the repeat-until loop at the following location:
I see there is a count variable which is sometimes incremented during the loop.
As a test I added a third condition to line 1307 to look like this:
Code: Select all
until (sf.AddrReturn.Offset = 0) or (rc > 1000) or (count > 1000);
Doing this no longer causes the program to freeze when the madExcept dialog shows.
Also the callstack is displayed correctly.
It consists of only one entry (since the code calling the delphi function was .net code (via COM)).
Please let me know if I can provide you with any other information.
If it helps I would be happy to do a remote debugging session with you, so you can make/use the debugger and troubleshoot the problem on my computer.
In case this helps, I saved to a txt file the current values of sf.AddrReturn.Offset and rc. This was done just above the until statement.
Code: Select all
DebugInfo.Add(Format('Offset: %d. rc: %d', [sf.AddrReturn.Offset, rc]));