2007/6/13, Christopher Kohlhoff
Daniel Albuschat wrote:
I experience crashes for certain types of replies.
The "crash" you see is asio's buffer debug checking in action. For whatever reason, it thinks one of the strings referred to in a buffer is no longer valid.
I'm pretty sure it actually *is* invalid.
What is different about those "certain types of replies"?
I could not trace that down. I've rewritten that part to be synchronous, so I do not have the lifetime-problem. There's a reply::to_string() function now: std::string reply::to_string() const { std::stringstream ss; ss << status_strings::to_string(status); for (std::size_t i = 0; i < headers.size(); ++i) { const header& h = headers[i]; ss << h.name << misc_strings::name_value_separator << h.value << misc_strings::crlf; } ss << misc_strings::crlf; ss << content; return ss.str(); } And I've changed the write-part of connection::handle_read as follows: request_handler_.handle_request(request_, reply_); std::string s = reply_.to_string(); boost::asio::write(socket_,boost::asio::buffer(s.data(),s.size())); connection_manager_.stop(shared_from_this()); It's not the optimal solution, but it's safe.
IMHO the whole content needs to be COPIED to new buffers and then, after the async_write finished, deleted.
Am I missing something? Was the author of this example not aware of the const_buffer's ownership policy (i.e. it is *not* owner of the data)?
I pretty sure I was aware ;) However that's not to say there are no bugs in the HTTP server or buffer debug checking.
As the reply is local to the connection, this should indeed work. I don't know where the problem lies exactly, probably it is a bug introduced by me at a different code-location. The server runs stable now, and I'll leave it at that. Since you seem to be the auther of the example: BIG THANKS to you, it really saved me MUCH time and I have a very very neat solution to connect my PHP script with the program-logic/database now. Regards, Daniel Albuschat -- eat(this); // delicious suicide