From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xry111@mengyan1223.wang>
Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23])
 by sourceware.org (Postfix) with ESMTPS id 9A8DE3858C56
 for <gcc-help@gcc.gnu.org>; Tue, 26 Apr 2022 15:17:23 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9A8DE3858C56
Received: from localhost.localdomain (localhost [127.0.0.1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-384))
 (Client did not present a certificate)
 (Authenticated sender: xry111@mengyan1223.wang)
 by mengyan1223.wang (Postfix) with ESMTPSA id 08C7466553;
 Tue, 26 Apr 2022 11:17:21 -0400 (EDT)
Message-ID: <0691ec5837c8bd354b780e123ced969615452331.camel@mengyan1223.wang>
Subject: Re: What's the possible reason of fclose core?
From: Xi Ruoyao <xry111@mengyan1223.wang>
To: okay <szy_mailbox@126.com>, gcc-help@gcc.gnu.org
Date: Tue, 26 Apr 2022 23:17:20 +0800
In-Reply-To: <a284584.6179.18066559d53.Coremail.szy_mailbox@126.com>
References: <a284584.6179.18066559d53.Coremail.szy_mailbox@126.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.1 
MIME-Version: 1.0
X-Spam-Status: No, score=-3031.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS,
 SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2022 15:17:26 -0000

On Tue, 2022-04-26 at 22:45 +0800, okay via Gcc-help wrote:
>=20
> #0=C2=A0 0x00007faad574d2a7 in raise () from /lib64/libc.so.6
> #1=C2=A0 0x00007faad574e67a in abort () from /lib64/libc.so.6
> #2=C2=A0 0x00007faad578c4f4 in __libc_message () from /lib64/libc.so.6
> #3=C2=A0 0x00007faad5791966 in malloc_printerr () from /lib64/libc.so.6
> #4=C2=A0 0x00007faad5791d02 in malloc_consolidate () from /lib64/libc.so.=
6
> #5=C2=A0 0x00007faad5792753 in _int_free () from /lib64/libc.so.6
> #6=C2=A0 0x00007faad5782bb9 in fclose@@GLIBC_2.2.5 () from /lib64/libc.so=
.6
>=20
> =C2=A0From the above core stack, because i can't see the parameter(file
> pointer, abbrv fp) value of fclose at frame 6, so fp=C2=A0 exists the
> following possible condition:
> 1) fp is NULL
> 2) fp is changed during running time
> 3) call fclose(fp)=C2=A0 twice continuously=20
> 4) others reason haven't guessed.
>=20
> =C2=A0 So i want to ask what's the possible condition can cause the above
> core?=20
> =C2=A0 Is it possible that other thread in same service change the fp val=
ue
> such as address violation operation?

gcc-help is not a proper channel to discuss such a topic without
anything specific to gcc.

That being said, you may try -fanalyzer which is helpful to catch the
condition (3).
--=20
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University