Vegeta panics and can lead to OS instability

[Tri125]

OS: Windows 64 bit Go: 1.9.1 Vegeta sha-1: f30b7dae680868cb930eafaf0df7d1801fd359e6

Command: echo "GET http://localhost:8080" | vegeta attack -rate 2000

I was running a service on port 8080 on my machine and I was playing with the rate option. I found that at a certain point the program will just panic after letting it run for a few seconds with a high amount of rate, for my system it was 2000.

It's difficult to know where exactly is the line causing the error since the program seems to repeatedly panic in a loop without exiting/handling the error. You can see what I mean by that by just querying localhost if you don't have anything listening on the port (it will repeatedly panic).

As for the other part of my report, under certain circumstance letting vegeta run can lead to the creation of a few problem. For instance, windows.exe can crash and bring doom to your entire desktop environment as well, possibly due to the sheer amount of garbage data being printed by the CLI. If I let it run for 5 seconds by querying localhost (if nothing is listening) the panics messages can crash windows.exe (I was able to do this twice, the third time it didn't). I'm confident that handling errors correctly will lessen this particular problem.

I've been able to reliably recreate those issues. if you would like videos or logs, I can provide them.

[tsenart]

Yes, provide the commands you’re running and the crash logs.

On Sunday, Oct 15, 2017 at 6:55 AM, Tristan <notifications@github.com (mailto:notifications@github.com)> wrote:

OS: Windows 64 bit Go: 1.9.1 Vegeta sha-1: f30b7da (https://github.com/tsenart/vegeta/commit/f30b7dae680868cb930eafaf0df7d1801fd359e6)

Command: echo "GET http://localhost:8080" | vegeta attack -rate 2000

I was running a service on port 8080 on my machine and I was playing with the rate option. I found that at a certain point the program will just panic after letting it run for a few seconds with a high amount of rate, for my system it was 2000.

It's difficult to know where exactly is the line causing the error since the program seems to repeatedly panic in a loop without exiting/handling the error. You can see what I mean by that by just querying localhost if you don't have anything listening on the port (it will repeatedly panic).

As for the other part of my report, under certain circumstance letting vegeta run can lead to the creation of a few problem. For instance, windows.exe can crash and bring doom to your entire desktop environment as well, possibly due to the sheer amount of garbage data being printed by the CLI. If I let it run for 5 seconds by querying localhost (if nothing is listening) the panics messages will crash windows.exe. I'm confident that handling errors correctly will lessen this particular problem.

I've been able to reliably recreate those issues. if you would like videos or logs, I can provide them.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (https://github.com/tsenart/vegeta/issues/266), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAEHjzKBGX1i8Q3rrxKlUUVCnVihMSROks5ssZBKgaJpZM4P5oVh).

[Tri125]

Good news, I was able to catch the beginning of the fatal error and a different error that I wasn't having yesterday but is more verbose. Sometimes I get error 1, sometimes error 2. Either way, the program won't stop by itself and it will litter the logs with errors.

Precondition:

A service listening to http traffic on localhost:8080/v0/cards.

Command:

echo "GET http://localhost:8080/v0/cards" | vegeta attack -rate 2000

Error 1:

runtime: VirtualAlloc of 1048576 bytes failed with errno=1455 fatal error: out of memory

Log: https://gist.github.com/Tri125/a99ab4a941ffe02fee82101c47c54c15

Error 2:

Get http://localhost:8080/v0/cards: dial tcp 0.0.0.0:0->[::1]:8080: bind: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.▒

[tsenart]

You need to pipe the output of vegeta attack to vegeta report.

[Tri125]

This is only the command to reproduce the issues.

Piping to the report command won't fix the attack command. In my opinion, it should exit on panic and print a single message instead of continuously printing the stack. It should also attempt not to create more connection than the machine can support or at the very least be less aggressive with its message output.

For users, piping is only required if they need the output for further processing which isn't necessarily the case. They might not be interested in any report if they only use vegeta to create a load on their servers.

[tsenart]

You're running out of resources. Try to run the attack with more memory available to vegeta.