When REMOTE_DB is set there is a thread for the web service, in
addition to the External modules thread manager, so there is one or two
threads by the end of the test run in addition to the main VM thread.
MSP-11147
Sometime travis-ci is showing leaked threads even when
'Msf::Framework#threads cleaner' is being used, so I'm adding the
`Thread#status` to the data printed about the Thread to see if the
sometimes leaked threads have an odd status. There's still a chance
that there will be a race-condition between when I call Thread.list and
I ask for each Thread's status that the VM could finish aborting a
Thread so that status I print isn't the same as the one that caused the
Thread to be returned in Thread.list.
MSP-11147
When using Rubymine's debugger, the tests would run and say there were
no tests and no break points would be hit. It was determined that this
was due the Rubymine's debugger injecting itself into RUBYOPTS and only
working if it's first in RUBYOPT, which means that
'metasploit:framework:spec:threads:suite' must inject '-Ilib
-rmetasploit/framework/spec/threads/logger' at the end of RUBOPT instead
of the beginning.
Have 'metasploit/framework/spec/threads/suite/logger' generate a UUID
for each Thread. This UUID is printed on the "BEGIN Thread.new caller"
line and is assigned as a thread-local variable,
'metasploit/framework/spec/threads/logger/uuid'. In `after(:suite)`,
the log can be parsed to map the caller back to each UUID and then only
the UUID of the still existing threads is used to look up the caller and
print their stacktraces. This means only leaked threads callers will be
printed.
MSP-11147
Even with leaked threads, there may be no log if the suite is run
without `rake spec`, such as when `rspec` is used directly to run a
subset of specs.
MSP-11147
Merge to get framework instance cleanup, which should clean up a lot of
thread leaks too.
Conflicts:
Rakefile
lib/metasploit/framework/spec.rb
spec/spec_helper.rb
MSP-11147
Detect thread leaks in a `before(:suite)` configured by
`Metasploit::Framework::Spec::Threads::Suite.configure!` and fail if any
leaks are found.
MSP-11130
Have a task, 'metasploit:framework:spec:constants:each:clean' run before
`rake spec` that removes the previous
`log/metasploit/framework/spec/constants/each.log` so that the user doesn't
have to manually remove the load when removing
`Metasploit::Framework::Spec::Constants::Each.configure!` from
`spec/spec_helper.rb`.
MSP-11130
Instead of writing `1` to the file and then printing a verbose message
in the spec task action, log the verbose message and just print the log
in the spec task action, so other tools can just look at the log when
not using `rake spec`.
NOTE: Failing specs due to unnecessary
`Metasploit::Framework::Spec::Constants::Each.configure!`
MSP-11130
When removing `Metasploit::Framework::Spec::Constants::Each.configure`
from spec/spec_helper.rb,
`Metasploit::Framework::Spec::Constants::Each.define_task` will see the
`log/remove-cleaner` from the last run unless it is manually removed.
MSP-11130
Some constants can be leaked before suite if module are loaded during
spec loading, such as if a framework instance in made in the context
body of a spec instead of in a before callback.
MSP-11130
Print to stderr the full description of the example when
`Metasploit::Framework::Spec::Constants.configure!`'s `before(:each)`
cleans constants as it may clean constants that are leaked from the
class level at parse time.
MSP-11130
Fail `rake spec` if
`Metasploit::Framework::Spec::Constants::Each.configure!`'s
`before(:each)` does not clean all leaked constants and if should be
removed so that it does not interefore with future specs.
MSP-11130
`Metasploit::Framework::Spec::Constants::Each.configure!` will set up an
`after(:each)` callback that will fail the example if there are leaked
constants. Leaked constants are cleaned up to prevent misattribution.
MSP-11130
`Metasploit::Framework::Spec::Constants::Suite` extracts out
`LOG_PATHNAME`, `configure!`, and `define_task` as those piece are
specific to handling constant leaks for the entire suite. This is in
preparation for `Metasploit::Framework::Spec::Constants::Each`.
MSP-11130
Constants from library Modules or Classes should not be reported as
leaked since they have been required and should be persistent between
spec runs.
MSP-11130
Extract method to convert child constant names to module full names so
it can be reused 'Metasploit::Framework::Spec::Constants tracker' shared
context.
MSP-11130
Instead of printing the leaked constants to stderr, log them to
`log/leaked-constants.log`. In task action for spec, read
`log/leaked-constants.log`. If it exists, print each leaked constants
(and it appropriate it's module full name) and then exit with 1. If the
file does not exist, do nothing.
MSP-11145
**NOTE: Failing specs**
Add a tool for reading `log/untested-payload.log` and
`framework.payloads` to determine `context`s to add
`spec/modules/payloads_spec.rb` to test the untested payloads.
MSP-11145
Extract the spec task action which errored out if
`log/untested-payloads.log` exists to
`Metasploit::Framework::Spec::UntestedPayloads.define_task`.
adfoster-r7