req.is_connection_closed() in high concurrency test leads to Segmentation fault

[WatsonYang1999]

Hi, I am using httplib v0.18.7 to implement a customized threadpool that can check if requests' connections are closed (using Request.is_connection_closed.
When using jmeter to test my server, the program crashed in is_socket_alive.
Following is the gdb stack.

[yhirose]

@WatsonYang1999 thanks for the report, but I don't know anything about jmeter. Also I can't give you any practical information since you are using your custom threadpool. Sorry about that...

[WatsonYang1999]

@yhirose Thanks for replying. Today I try to fix my bug by changing

  req.is_connection_closed = [&]() {
    return !detail::is_socket_alive(strm.socket());
  }

To

req.is_connection_closed = [strm_socket = strm.socket()]() { // obtain the socket in first place
  return !detail::is_socket_alive(strm_socket);
};

The major code change is to obtain socket in first place.

In my case, when I was trying to use is_connection_closed, strm object could be already deleted, and the behavior of strm.socket() could be undefined, therefore lead to segmentation fault.

Yet I have a another question, is the return value of strm.socket() a fixed one?

[yhirose]

What does it mean by a fixed one?

[WatsonYang1999]

@yhirose I’m initializing strm_socket with the value returned by strm.socket() when defining this lambda. Am I correct in assuming that the return value of strm.socket() will always be the same for each invocation? If so, I think I can modify this lambda to avoid my issue without causing other bugs.

[yhirose]

Yes, it's aways the same.

[yhirose]

@WatsonYang1999 your suggestion looks good to me. Please check with the latest httplib.h on the master branch.

[yhirose]

@WatsonYang1999 can you please explain how the situation "In my case, when I was trying to use is_connection_closed, strm object could be already deleted, and the behavior of strm.socket() could be undefined" is possible?