Bug#927154: aborts on window size change

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#927154: aborts on window size change

Antoine Beaupré-2
Package: myrepos
Version: 1.20180726
Severity: normal
Tags: upstream

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).

A simple reproducer is to start it the program on a large collection
(so it takes some time):

    mr -m -j8 update -q

then resize the window. mr will exit this way:

    $ mr -m -j8 update -q
    mr update: received signal 1

This happens when mr is started from xterm in a tiling window manager
(which immediately resizes the window):

    xterm -hold -e mr -m -j8 update  -q

... although in my experience this is not always fully
reproducible. Better to resize the window by hand, as the signal
might be fired before mr actually starts running (my guess).

Super strange, and breaks my sync scripts so it's really annoying. :)
But I guess it's not release critical...

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages myrepos depends on:
ii  perl  5.28.1-6

Versions of packages myrepos recommends:
ii  libfile-homedir-perl  1.004-1
ii  libhtml-parser-perl   3.72-3+b3
ii  libio-pty-easy-perl   0.10-1
ii  libwww-perl           6.36-1

Versions of packages myrepos suggests:
pn  ack | ack-grep    <none>
ii  bzr               2.7.0+bzr6622-15
ii  curl              7.64.0-2
ii  cvs               2:1.12.13+real-27
ii  darcs             2.14.1-3
ii  dgit              8.4
pn  fossil            <none>
ii  git [git-core]    1:2.20.1-2
ii  git-annex         7.20190129-3
pn  git-big-picture   <none>
ii  git-svn           1:2.20.1-2
pn  gitk | tig        <none>
pn  kdesdk-scripts    <none>
ii  liburi-perl       1.76-1
ii  mercurial         4.8.2-1
ii  perl-doc          5.28.1-6
pn  stow              <none>
ii  subversion        1.10.4-1
pn  subversion-tools  <none>
pn  unison            <none>
pn  vcsh              <none>
ii  xdg-utils         1.1.3-1

-- debconf-show failed

Reply | Threaded
Open this post in threaded view
|

Bug#927154: aborts on window size change

Paul Wise via nm
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?

--
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#927154: aborts on window size change

Antoine Beaupré-2
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 <[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

Bug#927154: aborts on window size change

Paul Wise via nm
On Mon, 2019-04-15 at 13:21 -0400, Antoine Beaupré wrote:

> Sure. Bisect tells me this one introduces the bug:

Thanks for that.

> I hope that helps.

That commit fixes a pretty major bug, so I think that maybe the issue
was present all along but masked by not using the right loop terminator.

I think it would be interesting to do the bisect again but for each
commit, cherry-pick the loop terminator fix before testing.

--
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#927154: aborts on window size change

Antoine Beaupré-2
On 2019-04-16 08:16:39, Paul Wise wrote:

> On Mon, 2019-04-15 at 13:21 -0400, Antoine Beaupré wrote:
>
>> Sure. Bisect tells me this one introduces the bug:
>
> Thanks for that.
>
>> I hope that helps.
>
> That commit fixes a pretty major bug, so I think that maybe the issue
> was present all along but masked by not using the right loop terminator.
>
> I think it would be interesting to do the bisect again but for each
> commit, cherry-pick the loop terminator fix before testing.

Ouch? Any practical way to do that?

It's kind of annoying there's no obvious way to automate the
reproducer. I tried to start it in tmux and it sometimes work, but not
reliably enough to automatically bisect...

And how would i reliable backport that patch systematically within
bisect anyways?

Thanks for any pointers...

a.

--
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
                        - Benjamin Franklin, 1755

Reply | Threaded
Open this post in threaded view
|

Bug#927154: aborts on window size change

Paul Wise via nm
On Tue, 2019-04-16 at 00:26 -0400, Antoine Beaupré wrote:

> Ouch? Any practical way to do that?

I think a normal `git bisect` but running `git cherry-pick` before
doing tests should work, untested though.

> And how would i reliable backport that patch systematically within
> bisect anyways?

Looks like it applies fine with `git cherry-pick` after checking out
1.20160123 so I suspect it will work fine with all the intermediary
commits anyway. To determine if the commit is included in the current
commit during the bisect, you can just `git grep is_active` or ask git
with the `git merge-base --is-ancestor 15e7a50 HEAD` exit code. If the
commit is already included, don't run `git cherry-pick`.

--
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#927154: aborts on window size change

Antoine Beaupré-2
On 2019-04-16 15:03:54, Paul Wise wrote:

> On Tue, 2019-04-16 at 00:26 -0400, Antoine Beaupré wrote:
>
>> Ouch? Any practical way to do that?
>
> I think a normal `git bisect` but running `git cherry-pick` before
> doing tests should work, untested though.
>
>> And how would i reliable backport that patch systematically within
>> bisect anyways?
>
> Looks like it applies fine with `git cherry-pick` after checking out
> 1.20160123 so I suspect it will work fine with all the intermediary
> commits anyway. To determine if the commit is included in the current
> commit during the bisect, you can just `git grep is_active` or ask git
> with the `git merge-base --is-ancestor 15e7a50 HEAD` exit code. If the
> commit is already included, don't run `git cherry-pick`.

Okay, so here's an interesting data point. On Debian stretch, I can't
reproduce the bug, even when running from git, using on current master
(1.20180726-30-g6cf8003).

So maybe something else is going on here, outside of myrepos itself...

I'll try to reproduce with the cherry-picking when I get back home on
that buster machine later.

A.
--
Sous un gouvernement qui emprisonne injustement, la place de l’homme
juste est aussi en prison.
                        - La désobéissance civile, Henry David Thoreau