There is a probability that gen_tcp:recv will get stuck indefinitely when used

imLaoYang · October 16, 2025, 2:36pm

When using gen_tcp:recv and encountering an infinite blocking situation, I found that the process was constantly waiting for Ref in prim_inet:recv0(). After checking, I discovered that it was because the Ref in the process message {inet_async, S, Ref, Status} was incorrect, always being one less than the required Ref.

jhogberg · October 16, 2025, 2:36pm

Thanks for raising this issue, what OTP version is this?

imLaoYang · October 16, 2025, 2:42pm

use OTP19.3, Is it because the version is too old that this issue occurs? The MySQL driver uses emysql, and the blocking problem happens in emysql when gen_tcp:recv gets stuck while receiving MySQL packet data.

jhogberg · October 16, 2025, 2:43pm

Yes, if it is what I think it is, I fixed this in OTP-19.3.6.10

github.com/erlang/otp

Fix a race condition when generating async operation ids

committed 06:39AM - 28 Jun 18 UTC

jhogberg

+5 -4

The counter used for generating async operation ids was a plain int shared betwe…en all ports, which was incorrect but mostly worked fine since the ids only had to be unique on a per-port basis. However, some compilers (notably GCC 8.1.1) generated code that assumed that this value didn't change between reads. Using a shortened version of enq_async_w_tmo as an example: int id = async_ref++; op->id = id; //A return id; //B In GCC 7 and earlier, `async_ref` would be read once and assigned to `id` before being incremented, which kept the values at A and B consistent. In GCC 8, `async_ref` was read when assigned at A and read again at B, and then incremented, which made them inconsistent if we raced with another port. This commit fixes the issue by removing `async_ref` altogether and replacing it with a per-port counter which makes it impossible to race with someone else.

imLaoYang · October 16, 2025, 3:02pm

"Thank you so much for promptly resolving this issue. I’ll upgrade the OTP version and run some tests. Our online project is a game server — could you recommend a stable OTP version? I’m really worried about running into similar issues again.

rlipscombe · October 16, 2025, 3:25pm

OTP-19.x support ended ~6 years ago. OTP-28.1 is the current supported version. See Erlang | endoflife.date, for a useful table.

imLaoYang · October 23, 2025, 9:41am

After I upgraded to 19.3.6.13, the current issue is that when the concurrency is high, the time for individual packets to be received by the client when using gen_tcp:send to send data is longer than before. In addition, I want to know if the return of “ok” after using gen_tcp:send means that this data packet has definitely been sent out.

jhogberg · October 23, 2025, 11:44am

That’s a separate problem which may have been mitigated in a later OTP release. It makes no sense for you to stay on a decade-old release, I think you will find that many of your issues will be fixed in OTP 28.1. By staying on such an old version you’re also missing out on the JIT that was introduced in OTP 24 (and further refined from then on).

“Yes,” in the sense that the operating system has promised that it has placed the data in the send buffer. However, it’s impossible to know whether the datagrams have been sent, let alone been received on the other end.

imLaoYang · October 23, 2025, 12:33pm

Thank you answer. Yes, I also think we need to upgrade to the latest stable version of Erlang. However, our current online project is running on OTP 19, and the version gap is quite large. We may need to develop a comprehensive testing plan after the upgrade.