From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) by sourceware.org (Postfix) with ESMTPS id 7BAAB3858D28 for ; Fri, 17 Mar 2023 15:57:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7BAAB3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-5416698e889so102422567b3.2 for ; Fri, 17 Mar 2023 08:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679068622; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8Xo6Gz9+Vv7FAC7cdNS2e+YJ2CwmLq97SpMSFWMbNDE=; b=RlvMC6AASXVagmtNBlbleoJwBmwzeWk+vNRPkqPHG8RnvZc9KslZV8iTbXF6ZSf3bD EQPHwzKG07WvbpHhqDOMdI6LS3I5w1HWAO1MXIiB8wbvTvouTTdiCmBSqwz9R/RpKbRr VzPGVjwCQx9SQakgb8V8zHSBUMKfDxGYn/D40wkD4LX+wfnbWmgXY+qbcq3CjhggtqE4 5vM4fh+1tkKySngBOLOg82dGUHAtRHYFv+LtcsY0WJawnHVJsQGBX7RDrBOYgr9fKGn5 m00xNrHQ8rl7G+bdv0nPROsMSVcq21lrt52szTmO2p3pUrIg3t5K6aaMISXGJmCE/woV tuJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679068622; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8Xo6Gz9+Vv7FAC7cdNS2e+YJ2CwmLq97SpMSFWMbNDE=; b=bNUyAPspT0OwmVsQqc3B398PSADXl67cH3GEbwtZZEL6mydEEEswO/jNOT43fuivU1 PJmTk7u5oRmOaat/Sa6/UPZJ3ms+qHN2CfRJl7yE2imgrp3Nmxxb0tvdXYw81t+AriTr /0YHInygxL7Khq6ufEymg1tuk/Y9TzomhOGcdULeHEo1cA9AvMwNCemZXXTaGicObDGW Yj5Va8PedKt/jHfKwYmeR2eu9T/CV5G0YyU/5tEJv49s6DFQLgr37i9Dgw+g99uzR/79 g+IektcN301d1RVlRSe6OacFjGMKLecqGLDefNonf/BYc92539vlSyxgCezM50Op+fHf Br0Q== X-Gm-Message-State: AO0yUKWGhUNb8IyWRhej0yP9IhXgU+KYL9apKWkj2zuNKAck5is0eJSk eHWkp7cPTchCmHFBHThYOcwiH0GUHlJtnkd3qyCOxoak X-Google-Smtp-Source: AK7set9mVdT6xdd4RTPo82oFYtfhczAT/TW5R0viIKyBwoOfSJD2yLunmxBM0SpGziVCCT0tGKFzi40Dlkc/J7zFdec= X-Received: by 2002:a81:656:0:b0:541:698b:7bdb with SMTP id 83-20020a810656000000b00541698b7bdbmr2372887ywg.2.1679068621789; Fri, 17 Mar 2023 08:57:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Fri, 17 Mar 2023 08:56:25 -0700 Message-ID: Subject: Re: strange segfault i386-dis.c:9815:28 To: Alan Modra Cc: Jan Beulich , binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3022.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Mar 17, 2023 at 3:41=E2=80=AFAM Alan Modra wrote= : > > Hi Jan, H.J., > I'm seeing some really weird oss-fuzz reports of segfaults in > i386-dis.c. > https://oss-fuzz.com/testcase-detail/5870018505342976 > https://oss-fuzz.com/testcase-detail/4651718416924672 > https://oss-fuzz.com/testcase-detail/5452642448179200 > > I can't reproduce them locally, and don't have access to the binaries > to see exactly what is going on. The problem may well turn out to be > a clang bug, but then there are these notes from the setjmp man page: > > "Consequently, the values of automatic variables are unspecified after > a call to longjmp() if they meet all the following criteria: > =E2=80=A2 they are local to the function that made the corresponding se= tjmp() call; > =E2=80=A2 their values are changed between the calls to setjmp() and lo= ngjmp(); and > =E2=80=A2 they are not declared as volatile." > > Jan's commit 384e201e5aec made "ins" an auto var. "priv" was already > an auto var. It might be possible that one or more of the "ins" or > "priv" fields are living in non-volatile regs and thus have stale > values after the longjmp. To cover that possibility, how about the > following patch? > > * i386-dis.c (print_insn): Access "ins" and "priv" via volatile > pointers after second sigsetjmp return. > > diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c > index a414e8c9b1e..9684dcda746 100644 > --- a/opcodes/i386-dis.c > +++ b/opcodes/i386-dis.c > @@ -9808,12 +9808,17 @@ print_insn (bfd_vma pc, disassemble_info *info, i= nt intel_syntax) > /* Getting here means we tried for data but didn't get it. That > means we have an incomplete instruction of some sort. Just > print the first byte as a prefix or a .byte pseudo-op. */ > - if (ins.codep > priv.the_buffer) > + volatile struct dis_private *ppriv =3D &priv; > + volatile instr_info *pins =3D &ins; > + if (pins->codep > ppriv->the_buffer) > { > const char *name =3D NULL; > > - if (ins.prefixes || ins.fwait_prefix >=3D 0 || (ins.rex & REX_O= PCODE)) > - name =3D prefix_name (&ins, priv.the_buffer[0], priv.orig_siz= eflag); > + if (pins->prefixes > + || pins->fwait_prefix >=3D 0 > + || (pins->rex & REX_OPCODE)) > + name =3D prefix_name (&ins, ppriv->the_buffer[0], > + ppriv->orig_sizeflag); > if (name !=3D NULL) > i386_dis_printf (&ins, dis_style_mnemonic, "%s", name); > else > @@ -9822,7 +9827,7 @@ print_insn (bfd_vma pc, disassemble_info *info, int= intel_syntax) > i386_dis_printf (&ins, dis_style_assembler_directive, > ".byte "); > i386_dis_printf (&ins, dis_style_immediate, "0x%x", > - (unsigned int) priv.the_buffer[0]); > + (unsigned int) ppriv->the_buffer[0]); > } > > return 1; > > -- > Alan Modra > Australia Development Lab, IBM Compilers should handle local variables with setjmp properly. Without a testcase, it is hard to tell what really went wrong. --=20 H.J.