From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13557 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: Mon, 17 Dec 2018 12:29:49 -0500 Message-ID: <20181217172949.GI23599@brightrain.aerifal.cx> References: <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> <20181212003639.GQ23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1545067679 16295 195.159.176.226 (17 Dec 2018 17:27:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Dec 2018 17:27:59 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13573-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 17 18:27:55 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 1gYwgM-00046S-IU for gllmg-musl@m.gmane.org; Mon, 17 Dec 2018 18:27:54 +0100 Original-Received: (qmail 25632 invoked by uid 550); 17 Dec 2018 17:30:03 -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 25614 invoked from network); 17 Dec 2018 17:30:02 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13557 Archived-At: On Mon, Dec 17, 2018 at 03:21:53PM +0100, Arkadiusz Sienkiewicz wrote: > Great, thank you for the fix. > Will it be available only in version 1.1.21 onward? Or will you also > backport it to older versions? Yes, it will be in 1.1.21. Generally I don't backport bugfixes within a release series. At first glance I thought it would be trivial to apply the relevant commit: https://git.musl-libc.org/cgit/musl/commit/?id=1a6d6f131bd60ec2a858b34100049f0c042089f2 and this one it depends on: https://git.musl-libc.org/cgit/musl/commit/?id=836022b1c3655f82cfc8ed5fc62006526ec73b8b However, it also depens on the following commit, which depends on the internal header wrappers and hidden-visibility framework that's new in this release cycle: https://git.musl-libc.org/cgit/musl/commit/?id=26c66c485c04fa782b8c6f7450bf008f4457b5a8 So some further tweaks would be needed if you really want to do this on older versions. If you can't do this yourself there are probably people in the community who'd be happy to do it as short contract work. Rich > śr., 12 gru 2018 o 01:36 Rich Felker napisał(a): > > > 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 > >