Re: sh(1) exiting on SIGWINCH
On 2012-Jul-05 00:22:45 -0500, Brandon Gooch jamesbrandongo...@gmail.com wrote: Seems that the window resize is somehow causing sh(1) to receive an EOF while the shell is sitting at the prompt, which results in the shell exiting; haven't dug too deeply into the source yet, but can you try to run /bin/sh with the '-I' (that's capital letter 'i') and it the shell shouldn't exit (but it will bark at you with a 'Use exit to leave shell.' message on each resize. Interesting. I hadn't tried '-I' but now also see that. I'm CC'ing jilles@ for any potential insight into the behavior of sh(1) (and perhaps this updated libedit snapshot). I would also welcome any insights jilles@ can offer. pfg@ (who shepherded the libedit update into the tree), David Shao (originator of kern/169603) and I have been investigating fixes to libedit but do not have a solution yet. There is a possibility that sh(1) is relying on bugs in the old libedit. At this stage, it seems likely that the libedit update (r237738) will be reverted for 9.1-RELEASE. -- Peter Jeremy pgpUCwQdtnSJm.pgp Description: PGP signature
Re: sh(1) exiting on SIGWINCH
Hello guys; --- Gio 5/7/12, Peter Jeremy pe...@rulingia.com ha scritto: Brandon Gooch jamesbrandongo...@gmail.com wrote: Seems that the window resize is somehow causing sh(1) to receive an EOF while the shell is sitting at the prompt, which results in the shell exiting; haven't dug too deeply into the source yet, but can you try to run /bin/sh with the '-I' (that's capital letter 'i') and it the shell shouldn't exit (but it will bark at you with a 'Use exit to leave shell.' message on each resize. Interesting. I hadn't tried '-I' but now also see that. I'm CC'ing jilles@ for any potential insight into the behavior of sh(1) (and perhaps this updated libedit snapshot). I would also welcome any insights jilles@ can offer. pfg@ (who shepherded the libedit update into the tree), David Shao (originator of kern/169603) and I have been investigating fixes to libedit but do not have a solution yet. There is a possibility that sh(1) is relying on bugs in the old libedit. At this stage, it seems likely that the libedit update (r237738) will be reverted for 9.1-RELEASE. I am trying hard to identify the specific changes from NetBSD that caused the issue. The problem is known to happen in the latest version of the upstream sources too but I don't want to revert all the patch if I can avoid it because it is becoming increasingly difficult update libedit and we need some of the new features. It seems like David Shao's issue is different but so far I am aware that the issue was introduced in the changes associated with read.c http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/read.c NetBSD fixed the SIGWINCH issue in revisions 1.55, 1.56 and 1.57 of that file but it was caused by revision 1.43 the EOF issue seems to be caused by Revision 1.49 I still have to play more with this. Pedro. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sh(1) exiting on SIGWINCH
Hello; --- Gio 5/7/12, Peter Jeremy pe...@rulingia.com ha scritto: ... pfg@ (who shepherded the libedit update into the tree), David Shao (originator of kern/169603) and I have been investigating fixes to libedit but do not have a solution yet. The following partial revert fixes things for me: http://people.freebsd.org/~pfg/patches/libedit/patch-169603 best regards, Pedro. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
sh(1) exiting on SIGWINCH
I've recently updated a box from 8-stable to 9-stable/amd64 (r237995), compiled with gcc, and now sh(1) exits if I change the window size (ssh'ing to the target system within an xterm). I don't recall ever seeing this sort of behaviour before and am still trying to track down the relevant code path. ktrace output looks like: 1766 sh GIO fd 2 wrote 2 bytes # 1766 sh RET write 2 1766 sh CALL ioctl(0,TIOCGETA,0x801020364) 1766 sh RET ioctl 0 1766 sh CALL ioctl(0,TIOCSETAW,0x801020338) 1766 sh RET ioctl 0 1766 sh CALL read(0,0x7fffda8f,0x1) 1766 sh RET read -1 errno 4 Interrupted system call 1766 sh PSIG SIGWINCH caught handler=0x417d10 mask=0x0 code=0x10006 1766 sh CALL sigreturn(0x7fffd600) 1766 sh RET sigreturn JUSTRETURN 1766 sh CALL ioctl(0,TIOCSETAW,0x80102030c) 1766 sh RET ioctl 0 1766 sh CALL setpgid(0,0x6e6) 1766 sh RET setpgid -1 errno 1 Operation not permitted 1766 sh CALL ioctl(0xa,TIOCSPGRP,0x7fffda74) 1766 sh RET ioctl 0 1766 sh CALL close(0xa) 1766 sh RET close 0 1766 sh CALL exit(0) Does this ring any bells with anyone? -- Peter Jeremy pgp5N9G6c8SWr.pgp Description: PGP signature
Re: sh(1) exiting on SIGWINCH
On 2012-Jul-04 20:03:32 +1000, Peter Jeremy pe...@server.rulingia.com wrote: I've recently updated a box from 8-stable to 9-stable/amd64 (r237995), compiled with gcc, and now sh(1) exits if I change the window size (ssh'ing to the target system within an xterm). I don't recall ever seeing this sort of behaviour before and am still trying to track down the relevant code path. Someone pointed me at kern/169603 and I can confirm that reverting r237738 (MFC of r237448) fixes the problem. Unfortunately, that is a fairly large patch and so I haven't investigated further. -- Peter Jeremy pgp3dL0c9CGxT.pgp Description: PGP signature
Re: sh(1) exiting on SIGWINCH
On Wed, Jul 4, 2012 at 5:08 PM, Peter Jeremy pe...@rulingia.com wrote: On 2012-Jul-04 20:03:32 +1000, Peter Jeremy pe...@server.rulingia.com wrote: I've recently updated a box from 8-stable to 9-stable/amd64 (r237995), compiled with gcc, and now sh(1) exits if I change the window size (ssh'ing to the target system within an xterm). I don't recall ever seeing this sort of behaviour before and am still trying to track down the relevant code path. Someone pointed me at kern/169603 and I can confirm that reverting r237738 (MFC of r237448) fixes the problem. Unfortunately, that is a fairly large patch and so I haven't investigated further. -- Peter Jeremy I just ran into this myself. Seems that the window resize is somehow causing sh(1) to receive an EOF while the shell is sitting at the prompt, which results in the shell exiting; haven't dug too deeply into the source yet, but can you try to run /bin/sh with the '-I' (that's capital letter 'i') and it the shell shouldn't exit (but it will bark at you with a 'Use exit to leave shell.' message on each resize. I'm CC'ing jilles@ for any potential insight into the behavior of sh(1) (and perhaps this updated libedit snapshot). Very disconcerting when I encountered this; glad I'm not alone on this one :) -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
