csuter / pyjdb Goto Github PK

test is currently flaky. still investigating.

possibly has something to do with

• initialization order of main thread vs child thread (see ThreadReferenceTest definition for test class detail)
• more remotely: javac optimization of test java code. the code basically does nothing (sleeps a couple threads), so maybe the compiler is eliminating code. adding println's affects behavior, somewhat in support of this theory. But it's much more likely the println's affect timing.

ideally, we would initiate connection, call VirtualMachine.Version(), load the appropriate spec, and give best effort support of all features. ideally backward incompatible features (ie, those that rely on later vm spec like generics in 5) need not expressly acknowledge backward incompatibility. it may be the case that post-java-5, this is much ado about nothing (or very little). then again, debugging legacy code sucks and there's probably plenty of stuff out there running on an older vm and it would be cool if folks could use this tool to make that drudgery a bit more "fun".

some functions are definitely not present between, say, 1.5 and 1.6. "capabilities" indicate this; codify them

observed at random when tests are run.

commit d3ede4d definitely affected

i've observed tests complete successfully, one fail (that uses event handling non-trivially), and hang on several different tests:

• ThreadReferenceTest.test_resume
• ClassTypeTest.invoke_method

appears to happen in Jdwp.register_event_callback

what are they? what are some examples? how do they work? is supporting them hard? why?

in the time between our finding it and using it for the test jvm jdwp port, there is nothing preventing the os from reusing the port we just ascertained to be unused a moment before. depending on port allocation scheme, may even be more likely than, say, trying random numbers above 10000 or something until it doesn't fail.