Hi Christian,
I worked with AI to try something like this does it help at all?
It is not exactly your code but got rid of file descriptor error.
These things were outlined on chatgpt...
thanks,
jim
A "bad file descriptor" error in your code can occur for several reasons. Here
are the most common causes:
Uninitialized or Invalid File Descriptor:
If the file descriptor is not properly initialized or has been closed before
it's used in pread or pwrite, you'll get an error.
File Descriptor from fork:
After a fork, both the parent and child processes have the same file
descriptors. If the parent process closes the file descriptor before the child
tries to read/write, the child will encounter a "bad file descriptor" error.
File Not Opened Successfully:
If open fails (e.g., due to permissions, invalid flags, or system limits), it
returns -1. If you do not check for this and use the returned value directly,
it can lead to a bad file descriptor error.
Incorrectly Using fopen:
If you mistakenly used fopen instead of open (as was in your original code),
the resulting file pointer would not be compatible with low-level operations
like pread and pwrite.
File Descriptor Limit Reached:
Each process has a limit on the number of file descriptors it can open
simultaneously. If this limit is exceeded, open will fail, and subsequent
attempts to use the invalid file descriptor will result in an error.
Closing the File Descriptor:
If close(fd) is called while the file descriptor is still being used by the
child process, it will cause a "bad file descriptor" error when the child tries
to use it.
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>
int main() {
int fd = open("pwrite.tmp", O_RDWR | O_CREAT, 0666);
int fd2 = open("pwrite.tmp", O_RDWR | O_CREAT, 0666);
if (fd < 0) {
perror("Error opening file");
return 1;
}
if (fd2 < 0) {
perror("Error opening file");
return 1;
}
char c = 42; // Example character to write
if (pwrite(fd, &c, sizeof(c), 0) < 0) {
perror("pwrite");
close(fd);
return EXIT_FAILURE;
}
// Forking a child process
pid_t pid = fork();
if (pid < 0) {
perror("fork");
if (!fd > -1)
close(fd);
return EXIT_FAILURE;
}
if (pid == 0) {
// Child process
if (pread(fd2, &c, sizeof(c), 0) < 0) {
perror("pread");
} else {
printf("Read character: %d\n", c); // Print the read character
}
_exit(EXIT_SUCCESS);
}
int status;
if (wait(&status) < 0) {
perror("wait");
}
if (close(fd2) < 0) {
perror("close");
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
Sent with Proton Mail secure email.
On Sunday, September 22nd, 2024 at 2:09 PM, Christian Franke via Cygwin
<cygwin@cygwin.com> wrote:
> Found during test of 'stress-ng --pseek ...' from current upstream
> stress-ng git HEAD:
>
> Testcase:
>
> $ uname -r
> 3.5.4-1.x86_64
>
> $ cat pfail.c
> #include <fcntl.h>
>
> #include <stdio.h>
>
> #include <unistd.h>
>
> #include <sys/wait.h>
>
>
> int main()
> {
> int fd = open("pwrite.tmp", O_RDWR|O_CREAT|O_BINARY, 0666);
> if (fd < 0) {
> perror("open"); return 1;
> }
>
> char c = 42;
> if (pwrite(fd, &c, 1, 0) < 0)
> perror("pwrite");
>
> if (fork() == 0) {
> if (pread(fd, &c, 1, 0) < 0)
> perror("pread");
> _exit(0);
> }
>
> int status;
> wait(&status);
> return 0;
> }
>
> $ make pfail
> cc pfail.c -o pfail
>
> $ ./pfail
> pread: Bad file descriptor
>
> $ strace ./pfail
> ...
> 617 75356 [main] pfail 10826 dofork: 10827 = fork()
> 82 11289 [main] pfail 10827 seterrno_from_nt_status:
> /usr/src/debug/cygwin-3.5.4-1/winsup/cygwin/fhandler/disk_file.cc:1883
> status 0xC0000008 -> windows error 6
>
> 80 75436 [main] pfail 10826 wait4: calling proc_subproc, pid -1,
> options 0
> 76 11365 [main] pfail 10827 geterrno_from_win_error: windows error
> 6 == errno 9
> 78 75514 [main] pfail 10826 proc_subproc: args: 5, -7728
> 64 11429 [main] pfail 10827 pread: -1 = pread(3, 0x7FFFFCC0B, 1,
> 0), errno 9
> ...
>
>
> The problem does not occur if there is no pread()/pwrite() before the
> fork(). This suggests that the child process inherits the extra handle
> value used to keep the original seek position, but not the actual handle.
>
> --
> Regards,
> Christian
>
>
> --
> Problem reports: https://cygwin.com/problems.html
> FAQ: https://cygwin.com/faq/
> Documentation: https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
