SIGSEGV when using `--http-port` option for dev server and port is already in use

[tomwheeler]

What are you really trying to do?

Describe the bug

With CLI version 0.12.0, I started a local development server with the --http-port option. Since I had already started one in another terminal window, I expected this to fail with a "port already in use" message. While it did do this, that message was followed by panic: runtime error: invalid memory address or nil pointer dereference, [signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x1023b3680], and a stack trace that obscured the "port already in use" message until I scrolled through 100 lines of output.

Minimal Reproduction

1. Install Temporal CLI version 0.12.0 and ensure that it's foremost in your executable path by running temporal --version
2. In one terminal, run temporal server start-dev --http-port 8234
3. In another terminal, run temporal server start-dev --http-port 8234
4. Observe that the second command fails immediately, as described above.

Environment/Versions

• OS and processor: M2 Mac running macOS Ventura 13.6.6 (22G630)
• Temporal Version: CLI = temporal version 0.12.0 (server 1.23.0) (ui 2.26.2)
• Are you using Docker or Kubernetes or building Temporal from source? No

Additional context

N/A

[tomwheeler]

I forgot to mention that I encountered this when I attempted to start the dev server using temporal server start-dev --http-port 8234 after having forgotten that I had started it a few hours earlier in another terminal.

[cretz]

So we would expect this to fail if the port is already in use, but the issue is how many lines to scroll to see that? I suspect this is a server issue and that if you started two servers on the same machine with the same ports configured the same thing would happen regardless of how you started those servers (CLI, via binary + config, etc).

Can you describe what the desired result is? Are you just looking for less output to see your error?

[tomwheeler]

Yes, I'd certainly expect the command to fail if the port is in use. What I did not expect is that, if using the --http-port option, the failure results in segmentation violation and panic (and therefore, significantly more output).

Having similar output for port conflicts whether or not that option is specified would provide a better user experience.

[cretz]

What I did not expect is that, if using the --http-port option, the failure results in segmentation violation and panic (and therefore, significantly more output).

I think this will happen with our server regardless of whether you use CLI. I think this may be a general server issue concerning port-in-use reaction instead of only something for CLI users. We can leave this open here, but after confirmation this is a server issue, it may be transferred to that repo.