Date: Mon, 7 May 2007 13:10:09 GMT From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/63197: tftp Bus error, core dumped Message-ID: <200705071310.l47DA9cH089160@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/63197; it has been noted by GNATS. From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: bug-followup@FreeBSD.org, freebsd@nbritton.org Cc: Subject: Re: bin/63197: tftp Bus error, core dumped Date: Sun, 06 May 2007 16:08:00 +0100 This is still a problem in -HEAD. As far as I can tell, the reason is as follows: We enable libedit's signal handling with "el_set(el, EL_SIGNAL, 1)" We also set up our own SIGINT signal handler, which essentially longjmp()s back to the start. Having a signal handler call longjmp is probably not a good idea anyway, but in conjunction with the libedit handler leads to the internal state of libedit becoming confused, and the next time libedit receives a signal (eg suspend, or resizing the window), libedit will die. Removing either of the two signal handlers prevents the crash, but it's not ideal as some functionality is lost. Switching off libedit's handling means that resumes or window resizes won't refresh the screen, removing the SIGINT handler means that transfers can't be stopped. I've tried calling el_reset after we receive the interrupt, but that doesn't help. OpenBSD have fixed this by having the signal handler only set an atomic flag, which is then regularly polled from the main code. Although it is worth noting that OpenBSD don't use libedit, so the fix can't be directly imported.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200705071310.l47DA9cH089160>