public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* What's the possible reason of fclose core?
@ 2022-04-26 14:45 okay
  2022-04-26 15:17 ` Xi Ruoyao
  2022-04-27 12:44 ` Florian Weimer
  0 siblings, 2 replies; 3+ messages in thread
From: okay @ 2022-04-26 14:45 UTC (permalink / raw)
  To: gcc-help


#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?

  Thanks!

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-04-27 12:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-26 14:45 What's the possible reason of fclose core? okay
2022-04-26 15:17 ` Xi Ruoyao
2022-04-27 12:44 ` Florian Weimer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).