We're note actually using Mubex, it might be causing a crash too
A problem we are seeing is that sometimes when BAP terminates (ie: jobs -K), we hit a deadlock while jobs are trying to cleanup, and sometimes that might cause msfconsole to crash and terminate. We suspect this Mubex is a contributing factor but it has been hard to prove because it's very hard to reproduce the crash.bug/bundler_fix
parent
6d30dfd93e
commit
dc0ce88279
|
@ -108,7 +108,7 @@ module Msf
|
||||||
if !custom_404.blank? && custom_404 !~ /^http/i
|
if !custom_404.blank? && custom_404 !~ /^http/i
|
||||||
raise Msf::OptionValidateError.new(['Custom404 (must begin with http or https)'])
|
raise Msf::OptionValidateError.new(['Custom404 (must begin with http or https)'])
|
||||||
end
|
end
|
||||||
@bes_mutex = Mutex.new
|
|
||||||
super
|
super
|
||||||
end
|
end
|
||||||
|
|
||||||
|
@ -144,14 +144,6 @@ module Msf
|
||||||
end
|
end
|
||||||
|
|
||||||
|
|
||||||
# Allows a block of code to access BES resources in a thread-safe fashion
|
|
||||||
#
|
|
||||||
# @param block [Proc] Block of code to sync
|
|
||||||
def sync(&block)
|
|
||||||
@bes_mutex.synchronize(&block)
|
|
||||||
end
|
|
||||||
|
|
||||||
|
|
||||||
# Returns the resource (URI) to the module to allow access to on_request_exploit
|
# Returns the resource (URI) to the module to allow access to on_request_exploit
|
||||||
#
|
#
|
||||||
# @return [String] URI to the exploit page
|
# @return [String] URI to the exploit page
|
||||||
|
|
Loading…
Reference in New Issue