From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13533 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 15:07:04 -0500 Message-ID: <20181207200704.GG23599@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> 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 1544213114 22966 195.159.176.226 (7 Dec 2018 20:05:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2018 20:05:14 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13549-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 07 21:05:10 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 1gVMN1-0005mg-Ve for gllmg-musl@m.gmane.org; Fri, 07 Dec 2018 21:05:08 +0100 Original-Received: (qmail 24179 invoked by uid 550); 7 Dec 2018 20:07:17 -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 24161 invoked from network); 7 Dec 2018 20:07:16 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13533 Archived-At: On Fri, Dec 07, 2018 at 01:05:53PM -0600, A. Wilcox wrote: > On 12/07/18 12:26, Rich Felker wrote: > > On Fri, Dec 07, 2018 at 11:31:01AM -0600, A. Wilcox wrote: > >> awilcox on gwyn [pts/7 Fri 7 11:29] ~: ./aioWrite > >> zsh: segmentation fault ./aioWrite > >> > >> (gdb) run > >> Starting program: /home/awilcox/aioWrite > >> [New LWP 60165] > >> [LWP 60165 exited] > >> aio_write/1-1.c cancelationStatus : 2 > >> Test PASSED > >> [Inferior 1 (process 60162) exited normally] > >> (gdb) quit > >> > > I don't think so. I'm concerned that it's a stack overflow, and that > > somehow the kernel folks have managed to break the MINSIGSTKSZ ABI. > > AIO threads use a PTHREAD_STACK_MIN-sized stack with no guard page > > (because they don't run any application code, just a tiny stub > > function) but this could overflow in kernelspace (and either crash or > > clobber memory depending on memory layout and presence/absence of > > ASLR) if the kernel is making a signal frame that's too big. Note that > > this would have to be nearly twice MINSIGSTKSZ (on x86 at least) due > > to rounding up to whole pages, so if the kernel is misbehaving here > > it's *badly* misbehaving... > > Note how for me, it runs correctly in gdb, but not bare. I can > reproduce this behaviour in valgrind, too: > > awilcox on gwyn [pts/7 Fri 7 13:03] ~: valgrind ./aioWrite > ==47650== Memcheck, a memory error detector > ==47650== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==47650== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info > ==47650== Command: ./aioWrite > ==47650== > --47650-- WARNING: unhandled ppc64be-linux syscall: 208 > --47650-- You may be able to write your own handler. > --47650-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > --47650-- Nevertheless we consider this a bug. Please report > --47650-- it at http://valgrind.org/support/bug_reports.html. > aio_write/1-1.c cancelationStatus : 2 > Test PASSED > ==47650== > ==47650== HEAP SUMMARY: > ==47650== in use at exit: 7,574 bytes in 5 blocks > ==47650== total heap usage: 6 allocs, 1 frees, 7,694 bytes allocated > ==47650== > ==47650== LEAK SUMMARY: > ==47650== definitely lost: 0 bytes in 0 blocks > ==47650== indirectly lost: 0 bytes in 0 blocks > ==47650== possibly lost: 0 bytes in 0 blocks > ==47650== still reachable: 7,168 bytes in 4 blocks > ==47650== suppressed: 406 bytes in 1 blocks > ==47650== Rerun with --leak-check=full to see details of leaked memory > ==47650== > ==47650== For counts of detected and suppressed errors, rerun with: -v > ==47650== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > > (syscall 208 is tkill) It runs ok for you under valgrind? It was messing up for me (crashing with static linking, getting stuck bad with dynamic) and that's what suggested stack overflow to me (since valgrind likely uses a lot of stack emulating stuff). This was on x86_64. Rich