Problems closing IDE

[Sonjli 5]

Hello,

I have two strange issues when closing IDE.

The first: IDE closes but it persist in memory so I have to kill the process

The second: The IDE closes but one or two of exceptions come to life

 

I have a lot of experts installed and I know for sure these problems are for this cause.

So, I tried to remove them one by one and open\close the IDE. I tried in various combinations. A lot of loss time. Every time a different behaviour.

The problem seems to be very random. If I have none of the experts installed, issues go away as if they never existed

 

I don't want THE solution, I understand.

 

My question is: is there any tool (logger, external debugger, etc.) to try to catch the problem?

 

Thanks

[dummzeuch 1456]

Exceptions on shutdown are particularly difficult to track down because lots of code gets executed at that time and not necessarily in the expected order. IDE plugins use the Open Tools API which consists of a set of interfaces which all go out of scope on shutdown. On top of that some plugins hack into the inner workings of the IDE to fix bugs, add functionality or change the UI (GExperts and cnwizards both do that). If you have several plugins installed they might also interfere with each other.

 

You can always run the IDE itself in the debugger and hope that in the case of an exception the call stack might give you some clues. But don't hold your breath, I have tried that for years and it rarely helped.

 

Having said that: I know that using the GExperts code formatter can cause access violations later on in the code editor or when exiting the IDE. This did not start when the code formatter was added to GExperts but already happened with the original DelFor expert from Egbert van Nes. Unfortunately these exceptions do not happen in the GExperts source code but somewhere in the IDE, so even in the debugger I  can only see the assembly code in the CPU window. I could also create them sometimes by simply copying and pasting large amounts of code, so I think it is not actually the code formatting that causes the problem but replacing the text of the whole editor file multiple times. There might be some background processing that gets confused by this operation. But I found no reliable way to reproduce them.

Edited June 5 by dummzeuch

[David Hoyle 68]

I have a lot of plugins installed in my IDE, many of my own + other like GExperts and MMX. I found my IDE became more stable after disabling all the Parnassus plugins. Haven't had the time to spend a day tracking down the issues to report a bug.

[JonRobertson 63]

1 hour ago, David Hoyle said:

I found my IDE became more stable after disabling all the Parnassus plugins.

When I initially installed Delphi 11.0, I went through GetIt and installed several items, including the Parnassus Bookmark and Threaded Debugging plugins. For the next couple of months, the Delphi IDE was more unstable than any previous version. It was bad enough that I emailed my account rep and she arranged an online call.

 

The short version is that once I uninstalled both Parnassus plugins, exceptions stopped occurring in the IDE. I occasionally see one today, but that is typically after having an instance of the IDE open for several hours using the debugger heavily.

[Navid Madani 1]

I, too, noticed that my IDE is significantly faster and more responsive without the Parnassus plugins. I have not had any crashes after a fresh install with the avoidance of all Parnassus plugins. Meanwhile, MMX has always been as solid as possible - thanks to Uwe Raabe.

[DelphiUdIT 145]

I have a lot of components installed and had no issue (except for know incompatibility beetwen "new Indy from repo" and "Embarcadero RAD Server Edge Components"). I don't usually use plugins, and I found the same like others told, Parnassus Debugger plugin emit every time some AV, either in debugger sessions (not often) or when closing Rad Studio with open project ( issue from old portal is RSP-43335, issue from new portal RSS-1243).

 

I simply use TaskManager ('analyzes waiting chain' or similar) and Process Explorer to find the module (apparently responsible).

 

[havrlisan 6]

It's a shame Parnassus Debugger gets so little attention from Embarcadero. Such a plugin should (IMO) be integrated into the IDE, it's an insanely helpful tool for debugging multi-threading applications. Unfortunately as mentioned above, having it installed brings in unbearable errors and slows down your entire workflow. The least they could do right now is add an option inside the plugin to disable it so it doesn't load until one needs it. Installing it every time (and then uninstalling it after use) is a pain in the ass.

[Sherlock 648]

4 minutes ago, havrlisan said:

The least they could do right now is add an option inside the plugin to disable it so it doesn't load until one needs it

GExperts has the Expert Manager to do just that. Perhaps give it a try.

[Navid Madani 1]

The Parnassus plugins are still maintained by David Millington, who probably has his hands full with C++ Builder's Clang adoption.  I don't think many existing C++ projects will be transitioned to C++ Builder, if not only for cost and C++ Builder's maintenance history. Meanwhile, the global C++ to Rust transition gaining momentum is a different story. 

[Lajos Juhász 270]

(In theory) Embarcadero tries to improove the quality of the integration. In case of the parallel debugger not the plugin is the reason but the IDE. According to David Millington it stresses the IDE and brings out error that would not surface during normal usage.