Date: Tue, 17 Nov 2015 17:25:14 +0100 From: Peter Blok <peter.blok@bsd4all.org> To: freebsd-hackers@freebsd.org Subject: regression after FreeBSD-EN-15:17.libc Message-ID: <EAE90EE5-8611-438C-B814-8FC48E62FFE5@bsd4all.org>
next in thread | raw e-mail | index | archive | help
Dear hackers, I have a strange problem with signal handling after the above errata was = implemented. It exposes itself after a slogin to a = FreeBSD-10.2-RELEASE-p7 and pressing Ctrl-C. It terminates the csh and = disconnects. This happens on two systems, one physical Octacore Atom and = on a virtual system at Hetzner. Both systems are in production and = amd64. Sources are in sync with svn. .cshrc is standard. I have tried to setup different test systems - one quad core Xeon and = one VMWare Fusion, running the exact same code, but they don=E2=80=99t = exhibit the problem. Besides the termination of the csh, I have seen corruptions in a db5 = database, after reboots. For example the sshguard database was garbled = after reboot. My suspicion is that it is signal related, caused by = reboot. This is why I am investigating further. I had a feeling it happened after the above errata change was = implemented. If I backout the changes everything works ok. If I put them = back in, it fails again. Checked the changes, but I can=E2=80=99t see anything wrong with them in = relation to the problem. Some other data points. - it doesn=E2=80=99t happen with ksh93 - it doesn=E2=80=99t happen after "exec csh -F=E2=80=9D which = doesn=E2=80=99t use vfork At one time I used ktrace and noticed the signal was delivered twice. I=E2=80=99ll make an exact clone of the Hetzner image and try to = reproduce it, but any other advice is welcome. Peter=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EAE90EE5-8611-438C-B814-8FC48E62FFE5>