From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13524 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 10:44:20 -0500 Message-ID: <20181207154419.GD23599@brightrain.aerifal.cx> References: 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 1544197353 21447 195.159.176.226 (7 Dec 2018 15:42:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Dec 2018 15:42:33 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Arkadiusz Sienkiewicz Original-X-From: musl-return-13540-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 07 16:42:29 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 1gVIGr-0005Ra-Ae for gllmg-musl@m.gmane.org; Fri, 07 Dec 2018 16:42:29 +0100 Original-Received: (qmail 18068 invoked by uid 550); 7 Dec 2018 15:44:38 -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 18046 invoked from network); 7 Dec 2018 15:44:37 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13524 Archived-At: On Fri, Dec 07, 2018 at 01:52:31PM +0100, Arkadiusz Sienkiewicz wrote: > Hi, > > I'm experiencing segmentation fault when I invoke aio_cancel on request > which is in EINPROGRESS state. This happens only with libc muls (used > version - 1.1.12-r8) and only on one (dual Intel Xeon Gold 6128) of few > computers I've tried it on - please let me know if you need more > information about that machine. Attached is very simple program > (aioWrite.cpp) that reproduces this problem. > > alpine-tmp-0:~$ ./aioWrite > Segmentation fault (core dumped) > > Bt from gdb shows problem is in aio_cancel. This is not correct: > > (gdb) r > Starting program: ~/aioWrite > [New LWP 70321] > > Program received signal ?, Unknown signal. > [Switching to LWP 70321] This just shows that the aio thread received the cancellation request. It's not a crash or a problem. However, gdb's reporting of it as "Unknown signal" and inability to pass it on correctly indicates that something is wrong with the gdb on your system. I've hit this issue a lot but it works on some systems and I don't recall what the cause/difference behind it is. We should work to figure that out and get an appropriate fix in distros that are affected. > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #define TNAME "aio_write/1-1.c" > > int main() { > char tmpfname[256]; > #define BUF_SIZE 512512 > char buf[BUF_SIZE]; > char check[BUF_SIZE+1]; > int fd; > struct aiocb aiocb; > int err; > int ret; > > snprintf(tmpfname, sizeof(tmpfname), "pts_aio_write_1_1_%d", getpid()); > unlink(tmpfname); > fd = open(tmpfname, O_CREAT | O_RDWR | O_EXCL, S_IRUSR | S_IWUSR); > if (fd == -1) { > printf(TNAME " Error at open(): %s\n", strerror(errno)); > exit(1); > } > > unlink(tmpfname); > > memset(buf, 0xaa, BUF_SIZE); > memset(&aiocb, 0, sizeof(struct aiocb)); > aiocb.aio_fildes = fd; > aiocb.aio_buf = buf; > aiocb.aio_nbytes = BUF_SIZE; > > if (aio_write(&aiocb) == -1) { > printf(TNAME " Error at aio_write(): %s\n", strerror(errno)); > close(fd); > exit(2); > } > > int cancellationStatus = aio_cancel(fd, &aiocb); > printf (TNAME " cancelationStatus : %d\n", cancellationStatus); > > /* Wait until completion */ > while (aio_error (&aiocb) == EINPROGRESS); > > close(fd); > printf ("Test PASSED\n"); > return 0; > } I just tried this test and it works for me on 32-bit x86. I'll try some other systems and see if I can reproduce the issue. It could be a bug in the test but I didn't see anything obviously wrong with it. Rich