all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "J.P." <jp@neverwas.me>
To: Fernando de Morais <fernandodemorais.jf@gmail.com>
Cc: "Mattias Engdegård" <mattiase@acm.org>,
	emacs-erc@gnu.org, bandali@gnu.org, 54458@debbugs.gnu.org
Subject: bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack overflow
Date: Mon, 25 Apr 2022 05:08:52 -0700	[thread overview]
Message-ID: <878rrtz7or.fsf__1326.61235272593$1650888633$gmane$org@neverwas.me> (raw)
In-Reply-To: <87ilqyrn9s.fsf@gmail.com> (Fernando de Morais's message of "Sun,  24 Apr 2022 21:59:27 -0300")

Fernando de Morais <fernandodemorais.jf@gmail.com> writes:

> Once more, sorry for the late response.

Not a problem! Plenty to do around here.

> I tested your patch (0003) and it worked the way you detailed: now I can
> do more than one transfer simultaneously, however, at some point I lose
> control of Emacs and regain it, completely, only when the transfers are
> finished.

I "believe" the simultaneous-receive problem and the loss-of-control
issue are unrelated (despite the second being exacerbated by the first).

> I believe I did something wrong when running `tcpdump' command, as it
> did not detect any files transferred through DCC GET in my tests and
> the dump file generated was always the same, 24 bytes, containing only
> one line.

No worries. I'll just assume the sender is behaving aberrantly. The
thing is, I still haven't been able to repro this with a real client as
sender. And when I asked around to see if anyone else has encountered
anything related, e.g.,

1. senders that never read
2. clients that always act defensively

I only got crickets for the second and for the first was told there's a
variant of the protocol (or some extension) called TSEND, which might be
to blame if enabled by a sender.

That said, I don't see an obvious problem with applying some version of
the proposed patches because we wouldn't be impacting routine behavior,
AFAICT. And since DCC has basically been deprecated for years, the risk
of incurring related hate mail is low should this observation prove
faulty.

> I found this approach very interesting and as soon as I could I tried to
> test it, but even in Emacs 28.1 I get the following error messages:
>
>    error in process sentinel: erc-format-message: No format spec for message dcc-get-failed
>    error in process sentinel: No format spec for message dcc-get-failed
>
> Is this an issue specific to the versions of Emacs (27.2 and 28.1) I
> tested it on?

Hm. And you applied *all* the patches as a sequence? I.e.,

  git am ~/somedir/000{1..4}-*.patch

Because the format spec lives in the first one:

  0001-Display-error-message-on-incomplete-ERC-DCC-transfer.patch

So that needs to be present (as do the rest). IOW, in this capacity,
they're acting as a set (not v1..vN iterations). Can you compare your
version of erc-dcc.el to the one on HEAD? BTW, I know for sure that they
won't apply cleanly on 27 (but they "should" on 28).

> Thank you so much for keeping investigating possible solutions. I'll be
> using your patches #2 and #3.

My pleasure! Thanks for reporting this. (FWIW, the subprocess thing
worked for me, but YMMV.)





  parent reply	other threads:[~2022-04-25 12:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-18 22:59 bug#54458: 27.2; erc-dcc-get: Re-entering top level after C stack overflow Fernando de Morais
2022-03-21 14:09 ` J.P.
2022-03-22 13:50   ` Fernando de Morais
2022-03-22 14:36     ` Eli Zaretskii
     [not found]       ` <87tubj1eq4.fsf@gmail.com>
2022-03-27 17:56         ` Eli Zaretskii
2022-03-27 22:09           ` Fernando de Morais
2022-03-27 20:54 ` Mattias Engdegård
2022-03-28  9:23   ` Mattias Engdegård
2022-03-28 11:14     ` Eli Zaretskii
2022-03-28 12:08       ` J.P.
2022-03-29 15:49         ` Mattias Engdegård
2022-03-29 16:45           ` Eli Zaretskii
2022-03-29 17:47             ` Mattias Engdegård
2022-03-29 19:44               ` J.P.
2022-03-30  4:02                 ` J.P.
     [not found]                 ` <87mth8rst7.fsf@neverwas.me>
2022-03-30 15:28                   ` Mattias Engdegård
2022-03-31 19:18                     ` J.P.
     [not found]                     ` <87sfqygccz.fsf@neverwas.me>
2022-04-03 17:20                       ` Fernando de Morais
2022-04-03 19:46                         ` J.P.
     [not found]                         ` <87wng67xxd.fsf@neverwas.me>
2022-04-10 21:31                           ` J.P.
     [not found]                           ` <875yng39sa.fsf@neverwas.me>
2022-04-11  3:17                             ` J.P.
     [not found]                             ` <87sfqkz4ts.fsf@neverwas.me>
2022-04-25  0:59                               ` Fernando de Morais
     [not found]                               ` <87ilqyrn9s.fsf@gmail.com>
2022-04-25 12:08                                 ` J.P. [this message]
     [not found]                                 ` <878rrtz7or.fsf@neverwas.me>
2022-04-29 14:51                                   ` Fernando de Morais
     [not found]                                   ` <87r15guen2.fsf@gmail.com>
2022-04-30 13:39                                     ` J.P.
     [not found]                                     ` <87ilqqy9km.fsf@neverwas.me>
2022-05-04 13:03                                       ` Fernando de Morais
     [not found]                                       ` <87pmkth2lr.fsf@gmail.com>
2022-05-06 13:06                                         ` J.P.
     [not found]                                         ` <874k22zu7s.fsf@neverwas.me>
2022-05-08  1:16                                           ` Fernando de Morais
     [not found]                                           ` <87sfpk4ydj.fsf@gmail.com>
2022-05-11 14:29                                             ` J.P.
     [not found]                                             ` <87ee10xhw3.fsf@neverwas.me>
2022-05-23  1:22                                               ` J.P.
2022-04-01  6:32                   ` J.P.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='878rrtz7or.fsf__1326.61235272593$1650888633$gmane$org@neverwas.me' \
    --to=jp@neverwas.me \
    --cc=54458@debbugs.gnu.org \
    --cc=bandali@gnu.org \
    --cc=emacs-erc@gnu.org \
    --cc=fernandodemorais.jf@gmail.com \
    --cc=mattiase@acm.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.