Last active
August 29, 2015 14:03
-
-
Save richardbuckle/e5205cdc9ad105741bb0 to your computer and use it in GitHub Desktop.
fopen() fails with ENOENT but open() works. WTF?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Verbatim LLDB session with an iPad Air running iOS 7.1.1. | |
| As you can see, "finPath", which is a const char*, is an absolute path. | |
| Normally fopen(finPath, "r") works fine but sometimes after stress-testing the app gets into a state where it always fails with ENOENT. | |
| How could fopen(finPath, "r") fail with ENOENT while open(finPath, O_RDONLY) succeeds? | |
| Edit: forgot to say that no memory warnings were received during the stress test. | |
| (lldb) p finPath | |
| (const char *) $17 = 0x00000001702dcfd1 "/var/mobile/Applications/91616646-D71F-451D-A14D-EC2BA61B99A5/Documents/inttest5/pdf/00002014" | |
| (lldb) p (FILE*)fopen(finPath, "r") | |
| (FILE *) $18 = 0x0000000000000000 | |
| (lldb) p errno | |
| (void *) $19 = 0x0000000000000002 | |
| (lldb) p (int)open(finPath, 0) | |
| (int) $20 = 275 | |
| (lldb) p (int)close($20) | |
| (int) $21 = 0 |
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Turns out that the app was leaking FILE*s. Case closed.