From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack overflow Date: Thu, 31 Mar 2022 23:32:12 -0700 Message-ID: <87fsmxe2kz.fsf__26750.4869889066$1648794927$gmane$org@neverwas.me> References: <78459EAB-314B-4122-8E3B-7F82685D0DBA@acm.org> <83a6da9vm8.fsf@gnu.org> <87r16m46uf.fsf@neverwas.me> <4DA2DB05-D902-42DF-860D-87617FBB74C8@acm.org> <83k0cc907r.fsf@gnu.org> <5A8EE4CF-6F5E-4119-8765-8E301E2BE935@acm.org> <87czi435nh.fsf@neverwas.me> <87mth8rst7.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25983"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: fernandodemorais.jf@gmail.com, emacs-erc@gnu.org, bandali@gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= To: 54458@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 01 08:35:19 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1naAsR-0006WL-8M for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 Apr 2022 08:35:19 +0200 Original-Received: from localhost ([::1]:57986 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1naAsQ-0004Hu-2G for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 Apr 2022 02:35:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1naAqE-0003JF-MG for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2022 02:33:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46770) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1naAqE-0008Mq-CI for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2022 02:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1naAqE-000423-9N for bug-gnu-emacs@gnu.org; Fri, 01 Apr 2022 02:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Apr 2022 06:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54458 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 54458-submit@debbugs.gnu.org id=B54458.164879474915433 (code B ref 54458); Fri, 01 Apr 2022 06:33:02 +0000 Original-Received: (at 54458) by debbugs.gnu.org; 1 Apr 2022 06:32:29 +0000 Original-Received: from localhost ([127.0.0.1]:40659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1naAph-00040r-26 for submit@debbugs.gnu.org; Fri, 01 Apr 2022 02:32:29 -0400 Original-Received: from mail-108-mta245.mxroute.com ([136.175.108.245]:41185) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1naApe-00040d-IJ for 54458@debbugs.gnu.org; Fri, 01 Apr 2022 02:32:27 -0400 Original-Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta245.mxroute.com (ZoneMTA) with ESMTPSA id 17fe3d3150a000fe85.002 for <54458@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 01 Apr 2022 06:32:15 +0000 X-Zone-Loop: e69575cb52c05bc8674311c51d93387f68f3a2731562 X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=V3RgT3fBUifyJKS9WltS0GzrKTRFJKmvwo9eNgl8NsY=; b=ZOUukfLNIRUmRkQYCjw45RAOV1 GYWzjfjFnybMP4IktGmYpaXUFzQ4dBEdlUd22LRmHQdi0UrPfquHXo8GuZDJbnVwQRd5mKbaOES4T XMJ23N0N7scap3DPcVWd2l7NHehb/+THpWfsCSdFcbZOC+t1dyNKIAT+ScvTq5MbLZyahRmu/okDh koXDl9LuI6nB+uRwfHIVcF69nAv9RyO7apb19Z8X72VuYpuRnWxBOGKYSI/frK/+psqDL/pqN9ACV 6HV/K4pDjDCfJBXqBFuYRMOQmTUARVcFwX0FSqxPKxRq23eQCKK4bjsJiIdHSUEh1nzofP8okfe7/ TlFiDodA==; In-Reply-To: <87mth8rst7.fsf@neverwas.me> (J. P.'s message of "Tue, 29 Mar 2022 21:02:44 -0700") X-AuthUser: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:229205 Archived-At: "J.P." writes: > BTW (cc. Fernando), the reason I simply dropped nested send attempts in > that earlier patch was because their payloads (those 4-byte receipts) > are only meaningful to a sender honoring "the spec" [1], which says > > The sender should not continue to transmit until the recipient has > acknowledged all data already transmitted. > > IOW, there shouldn't be prohibitive wire pressure when dealing with an > obedient sender, so we needn't worry about an outgoing receipt being > dropped (right?). And for corner-cutting senders, either those just > treating receipts as heartbeats and ignoring their contents or those > never bothering to read from the socket at all, "sparse but strictly > increasing" should always suffice, I think. If I'm wrong on either > count, we can always add more complexity. A quick note regarding the proposed implementation: the Qt-based graphical client KVIrc (free software) takes an identical tack WRT dropping instead of retrying denied sends. >From DccRecvThread::sendAck in src/modules/dcc/DccFileTransfer.cpp [1]: iRet = kvi_socket_send(m_fd, (void *)(ack), ackSize); if(iRet == ackSize) return true; // everything sent // When downloading from a fast server using send-ahead via an // asymmetric link (such as the common ADSL lines) it may happen that // the network output queue gets saturated with ACKs. In this case the // network stack will refuse to send our packet and we get here. // We should either retry to send the ACK in a while or avoid sending // it at all (as with send-ahead acks aren't usually checked // per-packet). if(iRet == 0) { // We can live with this: no data has been sent at all // Not sending the ack and hoping that the server will not // stall is better than killing the connection from our side // anyway. return true; } if(iRet < 0) { // Reported error. If it's EAGAIN or EINTR then no data has been sent. [...] if((err != EAGAIN) && (err != EINTR)) #endif //!(defined(COMPILE_ON_WINDOWS) || defined(COMPILE_ON_MINGW)) { // some other kind of error postErrorEvent(KviError::AcknowledgeError); return false; } return true; // no data sent: same as iRet == 0 above. } So if we stick to this approach and it turns out to be inadequate, at least we won't be alone in having fumbled. [1] https://github.com/kvirc/KVIrc/blob/e4a34cb9/src/modules/dcc/DccFileTransfer.cpp#L115