From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13537 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: aio_cancel segmentation fault for in progress write requests Date: Fri, 7 Dec 2018 16:12:12 -0500 Message-ID: <20181207211212.GJ23599@brightrain.aerifal.cx> References: <20181207154419.GD23599@brightrain.aerifal.cx> <20181207165217.GE23599@brightrain.aerifal.cx> <54b4d253-1660-3207-5d59-f23f1c25b2b9@adelielinux.org> <20181207182650.GF23599@brightrain.aerifal.cx> <03a5f237-87cd-5580-4148-a29fa22d3ef0@adelielinux.org> <20181207203532.GA2554@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1544217023 26633 195.159.176.226 (7 Dec 2018 21:10:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2018 21:10:23 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13553-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 07 22:10:19 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gVNO4-0006kf-4M for gllmg-musl@m.gmane.org; Fri, 07 Dec 2018 22:10:16 +0100 Original-Received: (qmail 17754 invoked by uid 550); 7 Dec 2018 21:12:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17729 invoked from network); 7 Dec 2018 21:12:24 -0000 Content-Disposition: inline In-Reply-To: <20181207203532.GA2554@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13537 Archived-At: On Fri, Dec 07, 2018 at 09:35:32PM +0100, Markus Wichmann wrote: > On Fri, Dec 07, 2018 at 01:13:44PM -0600, A. Wilcox wrote: > > So, my best theory is that running inside a debugger (gdb, valgrind) > > makes it slow enough that it no longer races. > > Two ideas to investigate further. 1: Produce a coredump ("ulimit -c > unlimited"). That won't interfere with timing, but I have no clue if > coredumps work with multithreading. > > 2: Might I suggest installing a SIGSEGV handler? If you have libunwind, > you can create a backtrace from inside the handler. And even if not, you > can at least print the exception PC, which would help a ton already. > > Only, don't return from that handler. Either _exit(), or better yet, > restore the default handler, then kill yourself with SIGSEGV. The signal handler will not work if the problem is stack overflow on the io thread. It runs with all signals blocked, and would need a sigaltstack to have space to run anyway, but there's nowhere to install a sigaltstack for the io thread. Rich