Bug 482206

Summary: Consider always adding 'remote debugging' set up to test framework (or write-up better instructions?)
Product: [Eclipse Project] Platform Reporter: David Williams <david_williams>
Component: RelengAssignee: Platform-Releng-Inbox <platform-releng-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3    
Version: 4.6   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:

Description David Williams CLA 2015-11-14 16:51:20 EST
Just a thought ... but, since I was just doing a little bit of it ... 

It seems we could, in theory, always add some relatively standard "remote debugging" library to the VM that runs the unit tests, and then, when needed, would be one less thing to do, to enable remote debugging. Would perhaps need a flag, to turn "off/on" depending on if simply "being there" causes slow downs or changes in behaviour. 

See 
http://developer.amd.com/resources/documentation-articles/articles-whitepapers/java-performance-when-debugging-is-enabled/


There could be better ways to do it, but when I did it locally, I added

<property
  name="extraVMargs"
  value="-agentlib:jdwp=transport=dt_socket,suspend=y,server=y,address=localhost:8000" />

to the library.xml file. The "address" values are the default in Eclipse. 

I was doing it locally, to try to find a bug in performance tests, and thought it might be related "running under Xfvb" since I could not reproduce it locally. [I could not reproduce it with remote debugger attached either .. but, that's another issue :) 

If being done while running on "Eclipse.org" would likely have to create a tunnel, or similar, since I believe 
"opening a port" would be a big deal. (Possible to do, temporarily, I'm sure, but would be time consuming). 

I guess if "always on", would have not always suspend. 

Just opening this so as to not lose the idea. As I think about it, probably better to simply write a good "how to" wiki page!