Apologies, for the late response, I had some other issues while trying to run/debug Swift on ubuntu and now it seems that It's (at least partially) working:
So basically I have 5-8 threads that run the following:
indent preformatted text by 4 spaces
func executeCommand(command: String, args: [String]) -> String {
let task = Process()
task.launchPath = command
task.arguments = args
let pipe = Pipe()
task.standardOutput = pipe
task.launch()
let data = pipe.fileHandleForReading.readDataToEndOfFile()
var output = NSString(data: data, encoding: String.Encoding.utf8.rawValue)
var output2 = output as! String;
return output2
}
public func fuzzOne(_ group: DispatchGroup) {
var parent = ""
var program = ""
var mutator = fuzzer.mutators.randomElement()
program = executeCommand(
command: "/bin/node",
args: ["/home/adrian/Downloads/fuzzers/idl-master/parse.js", "1","/var/www/html","PROD","justjs"])
let outcome = execute(program, stats: &mutator.stats)
}
Your code has plenty of things to be concerned about but I don’t see an obvious cause for this failure.
When it fails, do you get a Swift error? Or does the process die with a fatal error? An easy way to tell these apart is to set a breakpoint on swift_willThrow. Does it stop there? If so, what does the backtrace look like?
I must say I'm not a developer, especially not a swift developer.
Well, I’m especially not a Linux developer, so we’re well matched (-: Seriously though, if you’re programming in Swift you are, by my standards, a Swift developer!
This is the callstack:
Thanks. Unfortunately that didn’t help. In Linux the backtrace doesn’t include line numbers, just function offsets, which makes things challenging.
What Swift version are you using? That is, what does the following print?
$ swift --version
Swift version 5.3.3 (swift-5.3.3-RELEASE)
Target: x86_64-unknown-linux-gnu
Is there any chance you can cut this down to a test project that doesn’t depend on your Node.js code? Perhaps use Process to run some other, built-in tool instead? That’ll help for a couple of reasons:
By cutting down the project you eliminate a bunch of dependencies, one of which might be causing this problem. For example, this might not be a bug in Process but a bug elsewhere in your project that’s accidentally closing a file descriptor (that’s an easy mistake to make). Cutting down your project might reveal that.
Even if it doesn’t, you’ll have a small reproducible test case that you can supply when asking for help (or when filing a bug).
Are you able to run the strace tool on your binary? This will provide a log of the various system calls your program makes. It should tell us exactly which one is returning EBADF, and should also tell us whether you're closing an incorrect FD somewhere else in your program (hopefully).
thanks for the tip. I got the strace log, but looks like I'm not allowed to uploaded it here. It's too large for pastebin as well...
I tried to do some debugging myself based on that, however I couldn't see any syscall returning EBADF (or code 9 as shown in the above error) when doing a grep on the strace log.