GNU bug report logs -
#33018
26.1.50; thread starvation with async processes and accept-process-output
Previous Next
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
>> Cc: <michael.albinus <at> gmx.de>, <33018 <at> debbugs.gnu.org>
>> Date: Wed, 17 Oct 2018 18:37:00 +0100
>>
>> #0 0x00007ffff766a2a4 in __GI___libc_write (fd=1, buf=0x5555559c1b30, nbytes=4096)
>> at ../sysdeps/unix/sysv/linux/write.c:27
>> #1 0x00007ffff75fb56d in _IO_new_file_write (f=0x7ffff7739760 <_IO_2_1_stdout_>,
>> data=0x5555559c1b30, n=4096) at fileops.c:1203
>> #2 0x00007ffff75fa88f in new_do_write (fp=0x7ffff7739760 <_IO_2_1_stdout_>,
>> data=0x5555559c1b30 "pan></span></h2>\n<p>Emacs is primarily a <a
>> href=\"/wiki/Text_editor\" title=\"Text editor\">text editor</a> and is
>> designed for manipulating pieces of text, although it is capable of formatting
>> and print"..., to_do=to_do <at> entry=4096) at fileops.c:457
>> #3 0x00007ffff75fc6f9 in _IO_new_do_write (fp=<optimized out>, data=<optimized out>,
>> to_do=4096) at fileops.c:433
>> #4 0x00007ffff75fa6d8 in _IO_new_file_sync (fp=0x7ffff7739760 <_IO_2_1_stdout_>)
>> at fileops.c:813
>> #5 0x00007ffff75ef6ed in __GI__IO_fflush (fp=0x7ffff7739760 <_IO_2_1_stdout_>)
>> at iofflush.c:40
>> #6 0x00005555555918bb in write_data (out=0x7ffff7739760 <_IO_2_1_stdout_>, out2=0x0,
>> buf=0x5555559a9590 "pan></span></h2>\n<p>Emacs is primarily a <a
>> href=\"/wiki/Text_editor\" title=\"Text editor\">text editor</a> and is
>> designed for manipulating pieces of text, although it is capable of formatting
>> and print"..., bufsize=4096, skip=0x7fffffffd0e8,
>> written=0x7fffffffd0e0) at retr.c:207
>> #7 0x000055555559204f in fd_read_body (downloaded_filename=0x5555555e18a0 "-", fd=4,
>> out=0x7ffff7739760 <_IO_2_1_stdout_>, toread=198224, startpos=0, qtyread=0x7fffffffda20,
>> qtywritten=0x7fffffffd9d0, elapsed=0x7fffffffda28, flags=1, out2=0x0) at retr.c:498
>
> Looks like the buffer of the pipe through which Emacs reads the stuff
> is full, and wget waits for some space there?
Would that imply that different threads/processes are (re)using the same
buffer/pipe?
FWIW, strace -p <pip of stuck emacs> gives:
pselect6(14, [6 7], [], NULL, {tv_sec=99975, tv_nsec=320947003}, {NULL, 8}
and strace -p <pip of stuck wget> gives:
write(1, ">]</span></span></h2>\n<p>Emacs i"..., 4096
The former reminded me of bug#24201: https://debbugs.gnu.org/24201
--
Basil
This bug report was last modified 6 years and 239 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.