From owner-freebsd-stable@freebsd.org Thu Sep 28 00:01:12 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB533E1F32A for ; Thu, 28 Sep 2017 00:01:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from bat.yew.relay.mailchannels.net (bat.yew.relay.mailchannels.net [23.83.220.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F360A667E8 for ; Thu, 28 Sep 2017 00:01:09 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6863B20604D for ; Thu, 28 Sep 2017 00:00:59 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.131.244]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id C824E208891 for ; Thu, 28 Sep 2017 00:00:58 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [100.96.131.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Thu, 28 Sep 2017 00:00:59 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Illustrious-Wiry: 5e57cca34d19d403_1506556859251_805839455 X-MC-Loop-Signature: 1506556859250:2009194927 X-MC-Ingress-Time: 1506556859250 X-MHO-User: 15597574-a3e0-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 15597574-a3e0-11e7-a893-25625093991c; Thu, 28 Sep 2017 00:00:51 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8S00khc002842; Wed, 27 Sep 2017 18:00:46 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1506556846.31939.15.camel@freebsd.org> Subject: Re: [Asterisk-bsd] Asterisk13 coredump on freebsd 11.1 From: Ian Lepore To: Asterisk on BSD discussion , Tao Zhou , freebsd-stable , Konstantin Belousov , David Wetzel , Ed Maste Date: Wed, 27 Sep 2017 18:00:46 -0600 In-Reply-To: <81116454-105e-f72a-5251-a45aac100c22@selasky.org> References: <30f177e2-3fd7-37e7-2f77-4b43a56c6713@ish.com.au> <25f05b1c-34e5-aa88-39cc-55c9a7b15616@selasky.org> <81116454-105e-f72a-5251-a45aac100c22@selasky.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 00:01:12 -0000 On Thu, 2017-09-28 at 01:17 +0200, Hans Petter Selasky wrote: > Hi, >=20 > I just upgraded and hit these SEGFAULTs too. First of all you need > to=A0 > install GDB 8.0 from ports to get the right backtrace (important). > This=A0 > leads straight into LibUnwind in libgcc: >=20 > (gdb) bt > #0=A0=A0uw_frame_state_for (context=3Dcontext@entry=3D0x7fffdf3bbe20,=A0 > fs=3Dfs@entry=3D0x7fffdf3bbb70) > =A0=A0=A0=A0=A0at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/un= wind- > dw2.c:1249 > #1=A0=A00x0000000802cc8ffb in _Unwind_ForcedUnwind_Phase2=A0 > (exc=3Dexc@entry=3D0x804427230, > =A0=A0=A0=A0=A0context=3Dcontext@entry=3D0x7fffdf3bbe20) at=A0 > /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155 > #2=A0=A00x0000000802cc9334 in _Unwind_ForcedUnwind (exc=3D0x804427230,=A0 > stop=3D0x8024d5450 , > =A0=A0=A0=A0=A0stop_argument=3D) at=A0 > /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207 > #3=A0=A00x00000008024d52b3 in _Unwind_ForcedUnwind (ex=3D,=A0 > stop_func=3D0x7fffdf3bb948, stop_arg=3D0x804427000) > =A0=A0=A0=A0=A0at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:106 > #4=A0=A0thread_unwind () at > /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:172 > #5=A0=A0_pthread_exit_mask (status=3D, mask=3D) > =A0=A0=A0=A0=A0at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:257 > #6=A0=A00x00000008024d50db in _pthread_exit (status=3D0x804427000) at=A0 > /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:206 > #7=A0=A00x00000008024c7c0d in thread_start (curthread=3D0x804427000) > =A0=A0=A0=A0=A0at /usr/img/freebsd.11/lib/libthr/thread/thr_create.c:28= 9 > #8=A0=A00x00007fffdf340000 in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffdf3bc000 >=20 > libgcc uses this format which is OK: >=20 > (gdb) ptype struct _Unwind_Context > type =3D struct _Unwind_Context { > =A0=A0=A0=A0=A0_Unwind_Context_Reg_Val reg[18]; > =A0=A0=A0=A0=A0void *cfa; > =A0=A0=A0=A0=A0void *ra; > =A0=A0=A0=A0=A0void *lsda; > =A0=A0=A0=A0=A0struct dwarf_eh_bases bases; > =A0=A0=A0=A0=A0_Unwind_Word flags; > =A0=A0=A0=A0=A0_Unwind_Word version; > =A0=A0=A0=A0=A0_Unwind_Word args_size; > =A0=A0=A0=A0=A0char by_value[18]; > } >=20 > >=20 > > x86_64_freebsd_fallback_frame_state > > (struct _Unwind_Context *context, _Unwind_FrameState *fs) > > { > > =A0 struct sigframe *sf; > > =A0 long new_cfa; > >=20 > > =A0 /* Prior to FreeBSD 9, the signal trampoline was located > > immediately > > =A0=A0=A0=A0=A0before the ps_strings.=A0=A0To support non-executable = stacks on > > AMD64, > > =A0=A0=A0=A0=A0the sigtramp was moved to a shared page for FreeBSD > > 9.=A0=A0Unfortunately > > =A0=A0=A0=A0=A0this means looking frame patterns again > > (sys/amd64/amd64/sigtramp.S) > > =A0=A0=A0=A0=A0rather than using the robust and convenient KERN_PS_ST= RINGS > > trick. > >=20 > > =A0=A0=A0=A0=A0:=A0=A0lea=A0=A0=A0=A0=A00x10(%rsp),%rdi > > =A0=A0=A0=A0=A0:=A0=A0pushq=A0=A0=A0$0x0 > > =A0=A0=A0=A0=A0:=A0=A0mov=A0=A0=A0=A0=A0$0x1a1,%rax > > =A0=A0=A0=A0=A0:=A0=A0syscall > >=20 > > =A0=A0=A0=A0=A0If we can't find this pattern, we're at the end of the= stack. > > =A0 */ > >=20 > > =A0 if (!(=A0=A0=A0*(unsigned int *)(context->ra)=A0=A0=A0=A0=A0=A0=3D= =3D 0x247c8d48 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0^^^^ fault is triggered by th= is read access on the > stack > >=20 > > =A0=A0=A0=A0=A0=A0=A0=A0&& *(unsigned int *)(context->ra +=A0=A04) =3D= =3D 0x48006a10 > > =A0=A0=A0=A0=A0=A0=A0=A0&& *(unsigned int *)(context->ra +=A0=A08) =3D= =3D 0x01a1c0c7 > > =A0=A0=A0=A0=A0=A0=A0=A0&& *(unsigned int *)(context->ra + 12) =3D=3D= 0x050f0000 )) > > =A0=A0=A0=A0return _URC_END_OF_STACK; > >=20 > The code in question is trying to access the return address of the=A0 > caller on the stack which apparently I think is caught by the > recently=A0 > added MAP_GUARD feature: >=20 > https://svnweb.freebsd.org/changeset/base/320763 >=20 > I think this feature can be disabled by setting: > sysctl security.bsd.stack_guard_page=3D0 >=20 > And then restart Asterisk. Not sure if it helps, currently testing. > This my best guess why Asterisk started segfaulting when upgrading to > 11.1. >=20 > --HPS In 12-current we've switched to the unwind code from the llvm project. =A0I wonder if that can be MFC'd to 11? There are other problems in the contrib/gcc unwind code in 11 right now. =A0For example, I've been chasing what appears to be a clang codegen bug that prevents returning a value from a function that contains a call to __builtin_eh_return(). =A0That leads to a bogus return value getting misinterpretted and eventually abort() gets called when std::terminate() should be called instead due to an uncaught exception. -- Ian