On 2019-04-16 00:55:17, Paul Wise wrote:
> On Mon, 2019-04-15 at 12:10 -0400, Antoine Beaupre wrote:
>
>> Somewhere between 1.20160123 (debian stretch) and 1.20180726, myrepos
>> acquired this strange behavior that window change signals
>> (SIGWINCH/28?) seem to crash the program completely, when running in
>> paralell (-j) and minimal (-m).
>
> I've seen this before too but can't reproduce it easily.
> Would you mind bisecting to find the commit that causes it?
Sure. Bisect tells me this one introduces the bug:
[2]anarcat@curie:myrepos((57b5fa2...)|BISECTING)$ git bisect good
15e7a50ac16554a8eafe659cc28621fcbb388e5a is the first bad commit
commit 15e7a50ac16554a8eafe659cc28621fcbb388e5a
Author: Paul Wise <pa...@bonedaddy.net>
Date: Tue Feb 13 20:45:20 2018 +0800
Use $pty->getline and $pty->read as loop terminator instead of
$pty->is_active
If the command writes some data, waits a bit, writes some more data and then
exits quickly then not all of the output will be read because a small amount
of data will be read in the first loop while the process is still running,
then the process will have exited and the loop will terminate,
leaving the remaining output unread.
Using the read data as loop terminator ensures that it will all be read.
Found-by: diff -u <(pipetty mr -m status) <(pipetty mr -m status)
:100755 100755 b5495f3029a050ddd6930bb2b9860b1ec324bcb6
1849f0094b65061fed50be24079447b8244a03c9 M mr
I hope that helps.
A.
--
We should act only in such away that if everyone
else acted as we do, we would accept the results.
- Emmanuel Kant
