From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13548 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: Tue, 11 Dec 2018 19:36:39 -0500 Message-ID: <20181212003639.GQ23599@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> <87h8fpaypx.fsf@oldenburg2.str.redhat.com> <20181207201453.GH23599@brightrain.aerifal.cx> <87in049em2.fsf@oldenburg2.str.redhat.com> 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 1544574887 4760 195.159.176.226 (12 Dec 2018 00:34:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Dec 2018 00:34:47 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13564-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 12 01:34:43 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 1gWsU7-000180-82 for gllmg-musl@m.gmane.org; Wed, 12 Dec 2018 01:34:43 +0100 Original-Received: (qmail 3194 invoked by uid 550); 12 Dec 2018 00:36:52 -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 3176 invoked from network); 12 Dec 2018 00:36:52 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13548 Archived-At: On Mon, Dec 10, 2018 at 10:05:05AM +0100, Arkadiusz Sienkiewicz wrote: > Here are answers to some question directed to me earlier: > > > Could you attach the log from "strace -f -o strace.log ~/aioWrite"? > Sorry, can't do that. strace is not installed and I don't have root access. > If this is still needed I will ask admin to add strace. > > > Do the other machines have the same kernel (4.15.0-20-generic)? > No, other machines use kernel 4.15.0-39-generic. > > > Have you tried running the binary built on a successful machine on > the problematic machine? > > Yes, same effect - segmentation fault. bt from gdb is identical too. > > > valgrind might also be a good idea. > > alpine-tmp-0:~$ strace -f ./aioWrite > -sh: strace: not found > alpine-tmp-0:~$ valgrind > valgrind valgrind-di-server valgrind-listener > alpine-tmp-0:~$ valgrind ./aioWrite > ==70339== Memcheck, a memory error detector > ==70339== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > ==70339== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info > ==70339== Command: ./aioWrite > ==70339== > ==70339== Invalid free() / delete / delete[] / realloc() > ==70339== at 0x4C92B0E: free (vg_replace_malloc.c:530) > ==70339== by 0x4020248: reclaim_gaps (dynlink.c:478) > ==70339== by 0x4020CD0: map_library (dynlink.c:674) > ==70339== by 0x4021818: load_library (dynlink.c:980) > ==70339== by 0x4022607: load_preload (dynlink.c:1075) > ==70339== by 0x4022607: __dls3 (dynlink.c:1585) > ==70339== by 0x4021EDB: __dls2 (dynlink.c:1389) > ==70339== by 0x401FC8E: ??? (in /lib/ld-musl-x86_64.so.1) > ==70339== Address 0x4e9a180 is in a rw- mapped file > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so segment > ==70339== > ==70339== Can't extend stack to 0x4087948 during signal delivery for thread > 2: > ==70339== no stack segment > ==70339== > ==70339== Process terminating with default action of signal 11 (SIGSEGV): > dumping core > ==70339== Access not within mapped region at address 0x4087948 > ==70339== at 0x4016834: __syscall3 (syscall_arch.h:29) > ==70339== by 0x4016834: __wake (pthread_impl.h:133) > ==70339== by 0x4016834: cleanup (aio.c:154) > ==70339== by 0x40167B0: io_thread_func (aio.c:255) > ==70339== by 0x4054292: start (pthread_create.c:145) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== by 0x4053071: ??? (clone.s:21) > ==70339== If you believe this happened as a result of a stack > ==70339== overflow in your program's main thread (unlikely but > ==70339== possible), you can try to increase the size of the > ==70339== main thread stack using the --main-stacksize= flag. > ==70339== The main thread stack size used in this run was 8388608. > ==70339== > ==70339== HEAP SUMMARY: > ==70339== in use at exit: 81,051 bytes in 9 blocks > ==70339== total heap usage: 9 allocs, 3 frees, 81,051 bytes allocated > ==70339== > ==70339== LEAK SUMMARY: > ==70339== definitely lost: 0 bytes in 0 blocks > ==70339== indirectly lost: 0 bytes in 0 blocks > ==70339== possibly lost: 0 bytes in 0 blocks > ==70339== still reachable: 81,051 bytes in 9 blocks > ==70339== suppressed: 0 bytes in 0 blocks > ==70339== Rerun with --leak-check=full to see details of leaked memory > ==70339== > ==70339== For counts of detected and suppressed errors, rerun with: -v > ==70339== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 0 from 0) > Killed Based on discussions in the other branches of this thread and on IRC, I'm reasonably sure the cause of your crash is that your combination of kernel and cpu model produces very large signal frames that overflow the stack on the io thread. I have committed a solution to the problem which I plan to push soon, along with some additional improvements in this area. Rich