mr aborts with "received signal 1"

[Felix Eckhofer]

Since upgrading to cosmic I started to sometimes see the following behavior:

    $ mr -v -s --jobs 5 up
    mr: loading config /home/eckhofer/.mrconfig
    mr: including output of "cat ~/.config/mr/config.d/*"
    mr library now: [cut]
    mr update: running update >>vcsh run "$MR_REPO" git pull --ff-only "$@"<<
    mr update: /home/eckhofer/.config/vcsh/repo.d/bash.git
    mr update: received signal 1

I've only ever seen this when using the --jobs flag (though that might have been incidental) and it only happens from time to time (maybe around 10% chance?). Is there any way I can help debug this?

Version info:
    Ubuntu 18.10 (cosmic)
    myrepos 1.20180726 from cosmic/universe

[Felix Eckhofer (eckhofer)]

Seems definitely to be related to --jobs. I've had "--jobs" removed from my script for the last weeks and never seen it. Re-enabled it and sure enough, the error returned.

It's somewhat annoying, because updating my ~50 vcsh repos takes less than 3s with --jobs, but easily 30s without.

[Paul Wise (Debian) (pabs)]

I've bisected this issue and it is caused by this commit:

http://source.myrepos.branchable.com/?p=source.git;a=commitdiff;h=15e7a50ac16554a8eafe659cc28621fcbb388e5a

I've found that is a simple solution is to turn off pty size handling:

   my $pty = IO::Pty::Easy->new(handle_pty_size => 0);

I'm not sure if this is the correct fix so I haven't committed it yet.

 assignee pabs
 summary SIGWINCH causes `mr -j2` to exit with message "received signal 1"
 status inprogress

--
bye,
pabs

https://wiki.debian.org/PaulWise

[Paul Wise (Debian) (pabs)]

Niko Tyni from Debian pointed out the bug and the correct fix:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927154#55
http://source.myrepos.branchable.com/?p=source.git;a=commitdiff;h=0d8dc60c227cf5868e568c7fa30ebec1f770d521

 status fixcommitted

--
bye,
pabs

https://wiki.debian.org/PaulWise