Bug 21216
Summary: | Nasty Problem with fclose/ferror combination | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Garance A Drosehn <gad> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-11-22 05:02:33 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Garance A Drosehn
2000-11-22 01:23:40 UTC
libc is allowed to start nethack, format your disks, whatever it wants in this case. The fact that it magically works on some other system means nothing, the results of such operation are undefined. glibc in ferror has to acquire lock of the stream in question first (thus writes into memory). Perhaps other systems either don't care about multiple threads (and do no locking) or slow each operation down (by checking if the file descriptor is valid at the start of every single routine). You can turn some of such checks by recompiling glibc with IO_DEBUG, but as such checks just catch some cases and can pass even on invalid FILE descriptors and also slow things down, they are not enabled by default. So think about ferror on fclosed FILE as if you put random garbage into that memory area yourself. |