-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JDIType.throwDebugException() doesn't properly handle disconnected exception #192
Comments
iloveeclipse
added a commit
to iloveeclipse/eclipse.jdt.debug
that referenced
this issue
Mar 8, 2023
iloveeclipse
added a commit
to iloveeclipse/eclipse.jdt.debug
that referenced
this issue
Mar 8, 2023
exception (eclipse-jdt#192) TL;DR: simply don't override the super method - it does already the "right thing". See longer explanation in eclipse-jdt#192. Fixes eclipse-jdt#192
iloveeclipse
added a commit
that referenced
this issue
Mar 8, 2023
SarikaSinha
added a commit
that referenced
this issue
Mar 11, 2023
* Catch and log exceptions from IJDIEventListener during event dispatch IF IJDIEventListener.handleEvent() throws an exception during EventDispatcher.dispatch(), the debugger breaks. Stepping, resuming, terminating, etc. doesn't work. This change adds a try-catch block around IJDIEventListener.handleEvent() in EventDispatcher.dispatch(), to ensure faulty listeners don't break the debugger. Fixes: #172 * Disable GC for exception in ExceptionEvent until event is processed This change disables garbage collection for ExceptionEventImpl.fException, until the event is processed by listeners in EventDispatcher.dispatch(). Fixes: #167 * Check if AskRecurrenceDialog was cancelled and has null result (#176) Fixes #176 * Remove references to deprecated Navigator in Scrapbook editor It's up for removal thus offering it makes no sense. * Clean up duplicated code in JavaRuntime Replace the code checking if a classpath entry is modular with the new ClasspathEntry.isModular(). Fixes: #184 * POM and product version changes for 4.28 release Fixes eclipse-platform/eclipse.platform.releng.aggregator#916 * Bump bundle version for 4.28 (#192) See #192 * JDIType.throwDebugException() doesn't properly handle disconnected exception (#192) TL;DR: simply don't override the super method - it does already the "right thing". See longer explanation in #192. Fixes #192 --------- Co-authored-by: Simeon Andreev <simeon.danailov.andreev@gmail.com> Co-authored-by: Andrey Loskutov <loskutov@gmx.de> Co-authored-by: Александър Куртаков <akurtakov@gmail.com> Co-authored-by: Rahul Mohanan <rahul.mohanan@ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In our automated tests we see sometimes logged errors like:
The test doesn't expect that error in the log and fails (but would succeed without error log entry).
The error itself is unconditionally logged by the framework even if the debug listener works just fine & properly handles the case if the debug target is gone.
The error is logged because in JDIDebugElement.logError()
eclipse.jdt.debug/org.eclipse.jdt.debug/model/org/eclipse/jdt/internal/debug/core/model/JDIDebugElement.java
Line 56 in 0c8c6d9
the
getDebugTarget().isAvailable()
says "yes, I'm still there" even if JVM is already disconnected.The root cause of it is a subtle difference between
JDIType.throwDebugException()
andJDIDebugElement.throwDebugException()
: the overridden method inJDIType
doesn't callJDIDebugElement.disconnected()
, so afterJDIType.throwDebugException()
is called above withVMDisconnectedException
inJDIClassType.getSuperclass()
debug target is still assuming that JVM is connected.eclipse.jdt.debug/org.eclipse.jdt.debug/model/org/eclipse/jdt/internal/debug/core/model/JDIType.java
Line 77 in 0c8c6d9
The problem was introduced long time ago:
JDIDebugElement
code was copy/pasted toJDIType
and at that time original code did not had yetdisconnected()
call, see this commit.JDIDebugElement
was "cleaned up" anddisconnected()
call was added, but only in original code, not in the copied code, see this commit.JDIType
refactoring happened whereJDIType
extendedJDIDebugElement
see this commit but the method was already there and nobody noticed the small difference.What we learn: copy/paste is root of all evil.
I will provide a patch.
The text was updated successfully, but these errors were encountered: