From owner-svn-src-all@freebsd.org Tue Sep 3 14:06:18 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 541AEDC185; Tue, 3 Sep 2019 14:06:00 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N7yv4Pwnz4P4m; Tue, 3 Sep 2019 14:05:59 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 9875019F47; Tue, 3 Sep 2019 14:05:53 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 6392F194DE; Sun, 31 Mar 2019 12:10:35 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D06276856; Sun, 31 Mar 2019 12:10:35 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 0EBC0194DC; Sun, 31 Mar 2019 12:10:35 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 67B4A194DA for ; Sun, 31 Mar 2019 12:10:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8767776849; Sun, 31 Mar 2019 12:10:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2VCAFb8063504 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 31 Mar 2019 15:10:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2VCAFb8063504 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2VCAF3A063503; Sun, 31 Mar 2019 15:10:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f From: Konstantin Belousov To: Bruce Evans Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r345696 - head/lib/libvgl Message-ID: <20190331121015.GK1923@kib.kiev.ua> References: <201903291557.x2TFv9AW097226@repo.freebsd.org> <20190329182100.GZ1923@kib.kiev.ua> <20190330142319.I1011@besplex.bde.org> <20190330094558.GA1923@kib.kiev.ua> <20190331214235.K961@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190331214235.K961@besplex.bde.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 1D06276856 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:06:18 -0000 X-Original-Date: Sun, 31 Mar 2019 15:10:15 +0300 X-List-Received-Date: Tue, 03 Sep 2019 14:06:18 -0000 On Sun, Mar 31, 2019 at 10:27:54PM +1100, Bruce Evans wrote: > On Sat, 30 Mar 2019, Konstantin Belousov wrote: > > > On Sat, Mar 30, 2019 at 03:24:40PM +1100, Bruce Evans wrote: > >> On Fri, 29 Mar 2019, Konstantin Belousov wrote: > >> > >>> On Fri, Mar 29, 2019 at 03:57:09PM +0000, Bruce Evans wrote: > >>>> Author: bde > >>>> Date: Fri Mar 29 15:57:08 2019 > >>>> New Revision: 345696 > >>>> URL: https://svnweb.freebsd.org/changeset/base/345696 > >>>> > >>>> Log: > >>>> Fix endless loops for handling SIGBUS and SIGSEGV. > >>>> > >>>> r80270 has the usual wrong fix for unsafe signal handling -- just set > >>>> a flag and return to let an event loop check the flag and do safe > >>>> handling. This never works for signals like SIGBUS and SIGSEGV that > >>>> repeat and works poorly for others unless the application has an event > >>>> loop designed to support this. > >>>> > >>>> For these signals, clean up unsafely as before, except for arranging that > >>>> nested signals are fatal and forcing a nested signal if the cleanup doesn't > >>>> cause one. > >>>> > >>>> Modified: > >>>> head/lib/libvgl/main.c > >>>> > >>>> Modified: head/lib/libvgl/main.c > >>>> ============================================================================== > >>>> --- head/lib/libvgl/main.c Fri Mar 29 15:20:48 2019 (r345695) > >>>> +++ head/lib/libvgl/main.c Fri Mar 29 15:57:08 2019 (r345696) > >>>> ... > >>>> @@ -107,14 +107,22 @@ struct vt_mode smode; > >>>> } > >>>> > >>>> static void > >>>> -VGLAbort(int arg __unused) > >>>> +VGLAbort(int arg) > >>>> { > >>>> + sigset_t mask; > >>>> + > >>>> VGLAbortPending = 1; > >>>> signal(SIGINT, SIG_IGN); > >>>> signal(SIGTERM, SIG_IGN); > >>>> - signal(SIGSEGV, SIG_IGN); > >>>> - signal(SIGBUS, SIG_IGN); > >>>> signal(SIGUSR2, SIG_IGN); > >>>> + if (arg == SIGBUS || arg == SIGSEGV) { > >>>> + signal(arg, SIG_DFL); > >>>> + sigemptyset(&mask); > >>>> + sigaddset(&mask, arg); > >>>> + sigprocmask(SIG_UNBLOCK, &mask, NULL); > >>>> + VGLEnd(); > >>>> + kill(getpid(), arg); > >>> This of course misses the siginfo information from the real fault. > >> > >> It is in the nested signal frame. > >> > >>> Why SIGBUS/SIGSEGV are caught at all ? > >> > >> Otherwise, the screen is left in an application mode that the kernel > >> doesn't support (except to not write to the screen, so that the > >> application has full control). > > Also, the keyboard may be left in a strange state. Usually this is no > worse than termios raw mode, but it may be raw scancodes. In raw scancodes > mode, Alt-Fn to switch to another vty to fix the problem. libvgl disables > switching to another vty without going through a libvgl handler anyway. > The combination is usually enough to break switching to vty0 to run ddb, > though that should work for at least breakpoints in the kernel. IIRC, > sc_cngrab() switches the keyboard mode, and my version of it restores > ignoring of the anti-switch flag. > > > ... > > I am more about not doing kill(2) from the handler, instead do plain > > return to the context which caused the original signal. > > That won't work well for SIGBUS's and SIGSEGV's related to the library. > If the above cleanup is not done, then it is too hard to debug the problem, > and if the above cleanup is done then it is impossible to debug the original > problem if it was for and invalid access in libvgl code. > > The latter is a problem for the above cleanup too -- the cleanup clobbers > the libvgl state. > > However, I could do a more limited cleanup of just restoring the screen and > keyboard state using ioctls. ioctl() isn't async-signal safe in POSIX, but > most ioctls are async-signal safe in practice provided they don't use > global variables that were set too recently or too non-atomically. > VGLEnd() uses main globals established by VGLInit(). It depends on program > order which is not guaranteed in signal handlers for testing the flags set > by initialization. The cleanup now also does: > - screen clearing. This breaks debugging and is dangerous if the bug is > in screen clearing. Screen clearing is also very slow, and belongs > in the kernel. It is now done 4 times per libvgl use, but its > slowness is limited by the kernel not clearing properly and the > kernel not allowing the application to mmap() the whole physical > frame buffer in some versions of FreeBSD (this breaks panning). > - munmap(). This breaks debugging. > - free() of backing store buffer and the main VGLDisplay data. This breaks > debugging and is unnecessary if we are going to exit. You can only try to do async-safe calls from SIGSEGV handler, to not break a limited chances to success. Also you should not modify in-memory state for the library, for the same reason, and then it fits your goal of keeping the state intact for debugging. Then you should return to re-create the original situation causing and not kill(2). I find it weird to try to debug mode-switched code without serial console.