Description of the problem:

Bazel sometimes crashes when the path passed to --experimental_execution_log_file contains a number greater than Long.MAX_VALUE (9223372036854775807). This can also happen if you set --execution_log_json_file or --execution_log_binary_file because a temp file is created for the execution log file and it will have a large number in it.
Stack Trace:

java.lang.NumberFormatException: For input string: "99999999999999999999999999999999"
        at java.base/java.lang.NumberFormatException.forInputString(Unknown Source)
        at java.base/java.lang.Long.parseLong(Unknown Source)
        at java.base/java.lang.Long.parseLong(Unknown Source)
        at com.google.devtools.build.lib.profiler.Profiler$JsonTraceFileWriter.getSortIndex(Profiler.java:983)
        at com.google.devtools.build.lib.profiler.Profiler$JsonTraceFileWriter.enqueue(Profiler.java:851)
        at com.google.devtools.build.lib.profiler.Profiler.logTask(Profiler.java:557)
        at com.google.devtools.build.lib.profiler.Profiler.logSimpleTask(Profiler.java:580)
        at com.google.devtools.build.lib.unix.UnixFileSystem$ProfiledNativeFileOutputStream.write(UnixFileSystem.java:555)
        at java.base/java.io.BufferedOutputStream.write(Unknown Source)
        at java.base/java.io.FilterOutputStream.write(Unknown Source)
        at com.google.devtools.build.lib.util.io.AsynchronousFileOutputStream.lambda$new$0(AsynchronousFileOutputStream.java:67)
        at java.base/java.lang.Thread.run(Unknown Source)

This happens because

1. The Profiler tries to parse a number from every thread name
2. The SpawnLogModule creates an AsynchronousFileOutputStream, which spawns a thread with the name of the file in the thread's name.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

It's not deterministic because it depends on some async thread stuff, but I can get it to happend pretty regularly by building stuff with --experimental_execution_log_file=/tmp/exec99999999999999999999999999999999.log

Possible Fixes

1. Check the length of the number before you try to parse it
2. Catch the NumberFormatException exception and return MAX_SORT_INDEX;
3. Verify the thread name is one we care about before parsing the number

If you have any preference as to which solution to implement, I'd be happy to submit a PR.

What operating system are you running Bazel on?

Ubuntu 20.04

What's the output of bazel info release?

release 5.0.0