From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <i.kosarev@tarantool.org> Received: from smtp55.i.mail.ru (smtp55.i.mail.ru [217.69.128.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 2B6E2430D57 for <tarantool-patches@dev.tarantool.org>; Thu, 7 Nov 2019 15:07:21 +0300 (MSK) From: Ilya Kosarev <i.kosarev@tarantool.org> Date: Thu, 7 Nov 2019 15:07:14 +0300 Message-Id: <40e665ace244806d8ccd34286f3d64ef32b2c1c5.1573127783.git.i.kosarev@tarantool.org> In-Reply-To: <cover.1573127783.git.i.kosarev@tarantool.org> References: <cover.1573127783.git.i.kosarev@tarantool.org> In-Reply-To: <cover.1573127783.git.i.kosarev@tarantool.org> References: <cover.1573127783.git.i.kosarev@tarantool.org> Subject: [Tarantool-patches] [PATCH v5 1/3] httpc: fix assertion fail after curl write error List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org> List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe> List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/> List-Post: <mailto:tarantool-patches@dev.tarantool.org> List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help> List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe> To: tarantool-patches@dev.tarantool.org After executing curl request we need to process curl_request code. It might be CURLE_WRITE_ERROR. We had special case for it, which assumed diagnostic message being set and contained corresponding assert, though it is incorrect. Better way is to handle it as any other non-standard event. It was discovered while adding accept_encoding option. In case of unknown encoding curl_request code is currently set to CURLE_WRITE_ERROR and therefore we come to an assert assuming we have some diagnostics set. However, it is not being set and it is totally fine. This means we are failing on assert and it is not correct behavior. Prerequisites: #4232 --- src/httpc.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/httpc.c b/src/httpc.c index 8d18b9966..212064080 100644 --- a/src/httpc.c +++ b/src/httpc.c @@ -429,16 +429,12 @@ httpc_execute(struct httpc_request *req, double timeout) case CURLE_COULDNT_RESOLVE_PROXY: case CURLE_COULDNT_RESOLVE_HOST: case CURLE_COULDNT_CONNECT: + case CURLE_WRITE_ERROR: /* 595 Connection Problem (AnyEvent non-standard) */ req->status = 595; req->reason = curl_easy_strerror(req->curl_request.code); ++env->stat.failed_requests; break; - case CURLE_WRITE_ERROR: - /* Diag is already set by curl_write_cb() */ - assert(!diag_is_empty(&fiber()->diag)); - ++env->stat.failed_requests; - return -1; case CURLE_OUT_OF_MEMORY: diag_set(OutOfMemory, 0, "curl", "internal"); ++env->stat.failed_requests; -- 2.17.1