On Tue, 2022-04-26 at 22:45 +0800, okay via Gcc-help wrote: > > #0 0x00007faad574d2a7 in raise () from /lib64/libc.so.6 > #1 0x00007faad574e67a in abort () from /lib64/libc.so.6 > #2 0x00007faad578c4f4 in __libc_message () from /lib64/libc.so.6 > #3 0x00007faad5791966 in malloc_printerr () from /lib64/libc.so.6 > #4 0x00007faad5791d02 in malloc_consolidate () from /lib64/libc.so.6 > #5 0x00007faad5792753 in _int_free () from /lib64/libc.so.6 > #6 0x00007faad5782bb9 in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6 > > From the above core stack, because i can't see the parameter(file > pointer, abbrv fp) value of fclose at frame 6, so fp exists the > following possible condition: > 1) fp is NULL > 2) fp is changed during running time > 3) call fclose(fp) twice continuously > 4) others reason haven't guessed. > > So i want to ask what's the possible condition can cause the above > core? > Is it possible that other thread in same service change the fp value > 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). -- Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
