jdibug - Project Hosting on Google Code

Last 30 days Mar 04, 2010 issue 7 (Race condition when multiple breakpoints are in one class) reported by udalrich.schermer - What steps will reproduce the problem? 1. Set two breakpoints in a class that runs early in the program but is not loaded when the debugger connects. 2. Connect jdibug. There will be an error message that the class was not found 3. M-x jdibug-resume What is the expected output? What do you see instead? When the class is loaded, jdi-handle-class-prepare is called. At the end, it calls jdi-resume, then jdi-set-breakpoint. If the code reaches the second breakpoint soon after the class is loaded, it may proceed past that breakpoint before the breakpoint is set in the debugger. This is probably also possible with a single breakpoint, but multiple breakpoints increases the time window for the code to reach the unset breakpoint. A multi-core CPU is probably helpful in triggering this. What version of the product are you using? On what operating system? jdibug 0.2, cygwin on Windows NT, java 1.6 Please provide any additional information below. The following code at the end of jdi-handle-class-prepare appears to resolve the issue. (let (matched) (dolist (br (jdi-breakpoint-requests jdi)) (when (equal (jdi-breakpoint-request-source-file br) (jdi-class-signature-to-source jdi signature)) (jdi-set-breakpoint jdi (jdi-breakpoint-request-source-file br) (jdi-breakpoint-request-line-number br)) (jdi-trace "Set %s" br) (funcall (jdi-breakpoint-resolved-handler jdi) jdi br) (setq matched t))) (if matched (jdi-resume jdi)))))) What steps will reproduce the problem? 1. Set two breakpoints in a class that runs early in the program but is not loaded when the debugger connects. 2. Connect jdibug. There will be an error message that the class was not found 3. M-x jdibug-resume What is the expected output? What do you see instead? When the class is loaded, jdi-handle-class-prepare is called. At the end, it calls jdi-resume, then jdi-set-breakpoint. If the code reaches the second breakpoint soon after the class is loaded, it may proceed past that breakpoint before the breakpoint is set in the debugger. This is probably also possible with a single breakpoint, but multiple breakpoints increases the time window for the code to reach the unset breakpoint. A multi-core CPU is probably helpful in triggering this. What version of the product are you using? On what operating system? jdibug 0.2, cygwin on Windows NT, java 1.6 Please provide any additional information below. The following code at the end of jdi-handle-class-prepare appears to resolve the issue. (let (matched) (dolist (br (jdi-breakpoint-requests jdi)) (when (equal (jdi-breakpoint-request-source-file br) (jdi-class-signature-to-source jdi signature)) (jdi-set-breakpoint jdi (jdi-breakpoint-request-source-file br) (jdi-breakpoint-request-line-number br)) (jdi-trace "Set %s" br) (funcall (jdi-breakpoint-resolved-handler jdi) jdi br) (setq matched t))) (if matched (jdi-resume jdi)))))) Mar 04, 2010 issue 6 (Negative floats are shown as positive values in the debugger) reported by udalrich.schermer - What steps will reproduce the problem? 1. Compile code like the following public static void main(String[] args) { float f = -12.34f; System.out.println("f=" + f); } 2. Set a breakpoint on the println 3. Run and attach jdibug to the process What is the expected output? What do you see instead? The locals window should show "f = -12.34". Instead, it shows "f = 12.34" The problem is with jdwp-vec-to-float. It extracts the sign bit and then ignores it. It appears that the following code works correctly. (defun jdwp-vec-to-float (vec) (let* ((int (jdwp-vec-to-int vec)) (high (+ (* (elt vec 0) 256) (elt vec 1))) (sign (if (= 1 (lsh high -15)) -1 1)) (exponent (- (logand (lsh high -7) #xff) 127)) (mantissa (logand int #x7fffff)) result) (setq result (+ 1.0 (/ (float mantissa) #x7fffff))) (setq result (* sign result (expt 2 exponent))) result)) What version of the product are you using? On what operating system? Please provide any additional information below. What steps will reproduce the problem? 1. Compile code like the following public static void main(String[] args) { float f = -12.34f; System.out.println("f=" + f); } 2. Set a breakpoint on the println 3. Run and attach jdibug to the process What is the expected output? What do you see instead? The locals window should show "f = -12.34". Instead, it shows "f = 12.34" The problem is with jdwp-vec-to-float. It extracts the sign bit and then ignores it. It appears that the following code works correctly. (defun jdwp-vec-to-float (vec) (let* ((int (jdwp-vec-to-int vec)) (high (+ (* (elt vec 0) 256) (elt vec 1))) (sign (if (= 1 (lsh high -15)) -1 1)) (exponent (- (logand (lsh high -7) #xff) 127)) (mantissa (logand int #x7fffff)) result) (setq result (+ 1.0 (/ (float mantissa) #x7fffff))) (setq result (* sign result (expt 2 exponent))) result)) What version of the product are you using? On what operating system? Please provide any additional information below. Mar 03, 2010 issue 5 (No need to fail connection for invalid source paths) reported by jahlborn - What steps will reproduce the problem? 1. Setup jde-sourcepath with one or more invalid paths. 2. Attempt to connect What is the expected output? What do you see instead? Expect that the connect call would ignore the invalid paths and connect. Instead, i get an error message and the connection fails. What steps will reproduce the problem? 1. Setup jde-sourcepath with one or more invalid paths. 2. Attempt to connect What is the expected output? What do you see instead? Expect that the connect call would ignore the invalid paths and connect. Instead, i get an error message and the connection fails. Older Sep 08, 2009 r350 (fix static methods showing null as the receiving type) committed by ykphuah - fix static methods showing null as the receiving type fix static methods showing null as the receiving type Sep 08, 2009 r349 (fix exception when traversing to another frame) committed by ykphuah - fix exception when traversing to another frame fix exception when traversing to another frame Sep 08, 2009 r348 (handle quick stepping properly) committed by ykphuah - handle quick stepping properly handle quick stepping properly Sep 07, 2009 r347 (There's no problem with emacs23, just need to use nil instea...) committed by ykphuah - There's no problem with emacs23, just need to use nil instead of 0. There's no problem with emacs23, just need to use nil instead of 0. Sep 07, 2009 r346 (Improve performance by only resolving the object class once ) committed by ykphuah - Improve performance by only resolving the object class once Improve performance by only resolving the object class once Sep 07, 2009 r345 (added caching to improve performance) committed by ykphuah - added caching to improve performance added caching to improve performance Aug 05, 2009 r344 (we will provide jdibug from the build script) committed by ykphuah - we will provide jdibug from the build script we will provide jdibug from the build script Aug 05, 2009 r343 (no need another build directory) committed by ykphuah - no need another build directory no need another build directory Aug 05, 2009 r342 (so we can get the foo-debug-flag at compile time and also ru...) committed by ykphuah - so we can get the foo-debug-flag at compile time and also runtime so we can get the foo-debug-flag at compile time and also runtime Aug 05, 2009 r341 (define before use) committed by ykphuah - define before use define before use Aug 05, 2009 r340 (cleanup) committed by ykphuah - cleanup cleanup Aug 05, 2009 r339 (add ending newline) committed by ykphuah - add ending newline add ending newline Aug 05, 2009 r338 (we use jdibug.el for the final distributable) committed by ykphuah - we use jdibug.el for the final distributable we use jdibug.el for the final distributable Aug 05, 2009 r337 (we use jdibug.el for the final distributable) committed by ykphuah - we use jdibug.el for the final distributable we use jdibug.el for the final distributable Aug 05, 2009 r336 (we use jdibug.el for the final distributable) committed by ykphuah - we use jdibug.el for the final distributable we use jdibug.el for the final distributable Aug 05, 2009 r335 (not needed) committed by ykphuah - not needed not needed Aug 05, 2009 r334 (my version for byte compilation) committed by ykphuah - my version for byte compilation my version for byte compilation Aug 05, 2009 r333 (my version for byte compilation) committed by ykphuah - my version for byte compilation my version for byte compilation Aug 05, 2009 r332 (supports byte compilation) committed by ykphuah - supports byte compilation supports byte compilation Aug 04, 2009 r331 (fix byte compile errors) committed by ykphuah - fix byte compile errors fix byte compile errors Aug 04, 2009 r330 (implemented multiple functions setter) committed by ykphuah - implemented multiple functions setter implemented multiple functions setter Aug 04, 2009 r329 (display id for custom setters as well) committed by ykphuah - display id for custom setters as well display id for custom setters as well Aug 04, 2009 r328 (handle thread-start and thread-end and refresh the frames bu...) committed by ykphuah - handle thread-start and thread-end and refresh the frames buffer handle thread-start and thread-end and refresh the frames buffer Aug 03, 2009 r327 (previous implemention shows that every thread is a daemon th...) committed by ykphuah - previous implemention shows that every thread is a daemon thread previous implemention shows that every thread is a daemon thread Aug 03, 2009 r326 (follow eclipse that displays daemon if the thread is daemon) committed by ykphuah - follow eclipse that displays daemon if the thread is daemon follow eclipse that displays daemon if the thread is daemon Aug 03, 2009 r325 (cleanup) committed by ykphuah - cleanup cleanup Aug 03, 2009 r324 (using 0 seems to create a lot of timeouts) committed by ykphuah - using 0 seems to create a lot of timeouts using 0 seems to create a lot of timeouts Aug 03, 2009 r323 (cleanup) committed by ykphuah - cleanup cleanup Aug 03, 2009 r322 (cleanup) committed by ykphuah - cleanup cleanup Aug 03, 2009 r321 (when resuming and there are other suspended threads, continu...) committed by ykphuah - when resuming and there are other suspended threads, continue from those when resuming and there are other suspended threads, continue from those Aug 03, 2009 r320 (workaround for bug in emacs23) committed by ykphuah - workaround for bug in emacs23 workaround for bug in emacs23 Aug 03, 2009 r319 (fix error) committed by ykphuah - fix error fix error Aug 03, 2009 r318 (too much noise) committed by ykphuah - too much noise too much noise Aug 03, 2009 r317 (like eclipse, differentiate receiving and declaring type in ...) committed by ykphuah - like eclipse, differentiate receiving and declaring type in frames like eclipse, differentiate receiving and declaring type in frames Aug 03, 2009 r316 (better handling when connection refused) committed by ykphuah - better handling when connection refused better handling when connection refused Aug 03, 2009 r315 (handle debuggess that are started with suspend=y) committed by ykphuah - handle debuggess that are started with suspend=y handle debuggess that are started with suspend=y Aug 02, 2009 r314 (fix expanding arrays of 0 entries) committed by ykphuah - fix expanding arrays of 0 entries fix expanding arrays of 0 entries Aug 02, 2009 r313 (install classprepare on unresolved breakpoints) committed by ykphuah - install classprepare on unresolved breakpoints install classprepare on unresolved breakpoints Aug 02, 2009 r312 (better constant names) committed by ykphuah - better constant names better constant names Aug 02, 2009 r311 (cleanup) committed by ykphuah - cleanup cleanup Aug 02, 2009 r310 (fixed resuming) committed by ykphuah - fixed resuming fixed resuming Aug 02, 2009 r309 (make sure we don't call process-send-string within the proce...) committed by ykphuah - make sure we don't call process-send-string within the process filter make sure we don't call process-send-string within the process filter Aug 02, 2009 r308 (shouldnt cache the frames) committed by ykphuah - shouldnt cache the frames shouldnt cache the frames Aug 02, 2009 r307 (cleanup) committed by ykphuah - cleanup cleanup Aug 02, 2009 r306 (timers running within jdwp seems to create problems, frames ...) committed by ykphuah - timers running within jdwp seems to create problems, frames buffer not being refreshed properly timers running within jdwp seems to create problems, frames buffer not being refreshed properly Aug 02, 2009 r305 (handle use case of multiple suspended threads) committed by ykphuah - handle use case of multiple suspended threads handle use case of multiple suspended threads Aug 02, 2009 r304 (fixes and mock handling for event start/stop) committed by ykphuah - fixes and mock handling for event start/stop fixes and mock handling for event start/stop

issue 7 (Race condition when multiple breakpoints are in one class) reported by udalrich.schermer - What steps will reproduce the problem? 1. Set two breakpoints in a class that runs early in the program but is not loaded when the debugger connects. 2. Connect jdibug. There will be an error message that the class was not found 3. M-x jdibug-resume What is the expected output? What do you see instead? When the class is loaded, jdi-handle-class-prepare is called. At the end, it calls jdi-resume, then jdi-set-breakpoint. If the code reaches the second breakpoint soon after the class is loaded, it may proceed past that breakpoint before the breakpoint is set in the debugger. This is probably also possible with a single breakpoint, but multiple breakpoints increases the time window for the code to reach the unset breakpoint. A multi-core CPU is probably helpful in triggering this. What version of the product are you using? On what operating system? jdibug 0.2, cygwin on Windows NT, java 1.6 Please provide any additional information below. The following code at the end of jdi-handle-class-prepare appears to resolve the issue. (let (matched) (dolist (br (jdi-breakpoint-requests jdi)) (when (equal (jdi-breakpoint-request-source-file br) (jdi-class-signature-to-source jdi signature)) (jdi-set-breakpoint jdi (jdi-breakpoint-request-source-file br) (jdi-breakpoint-request-line-number br)) (jdi-trace "Set %s" br) (funcall (jdi-breakpoint-resolved-handler jdi) jdi br) (setq matched t))) (if matched (jdi-resume jdi))))))

What steps will reproduce the problem? 1. Set two breakpoints in a class that runs early in the program but is not loaded when the debugger connects. 2. Connect jdibug. There will be an error message that the class was not found 3. M-x jdibug-resume What is the expected output? What do you see instead? When the class is loaded, jdi-handle-class-prepare is called. At the end, it calls jdi-resume, then jdi-set-breakpoint. If the code reaches the second breakpoint soon after the class is loaded, it may proceed past that breakpoint before the breakpoint is set in the debugger. This is probably also possible with a single breakpoint, but multiple breakpoints increases the time window for the code to reach the unset breakpoint. A multi-core CPU is probably helpful in triggering this. What version of the product are you using? On what operating system? jdibug 0.2, cygwin on Windows NT, java 1.6 Please provide any additional information below. The following code at the end of jdi-handle-class-prepare appears to resolve the issue. (let (matched) (dolist (br (jdi-breakpoint-requests jdi)) (when (equal (jdi-breakpoint-request-source-file br) (jdi-class-signature-to-source jdi signature)) (jdi-set-breakpoint jdi (jdi-breakpoint-request-source-file br) (jdi-breakpoint-request-line-number br)) (jdi-trace "Set %s" br) (funcall (jdi-breakpoint-resolved-handler jdi) jdi br) (setq matched t))) (if matched (jdi-resume jdi))))))

Last 30 days

Older