| View previous topic :: View next topic |
| Author |
Message |
Harry
Guest
|
 Posted: Tue Aug 26, 2008 4:53 pm Post subject: Bad File Descriptor error |
 |
|
Dear all,
I am facing a problem with device open and write.
I have written an application in linux on a embedded device running
linux.
I have a printer device interfaced to the processor serial port.
Write() to the device fails at time.perror() shows Bad file descriptor
error. When i printed the file descriptor value, i found it to be 0.
AFAK, file descriptor value of 0 is for stdin.Is that correct?
I am opening the device in Read Write mode with NONBLOCK and NOCTTY
flags.
Any idea of where i may be wrong? |
|
| |
|
 Back to top |
Bill Marcum
Guest
|
| Posted: Wed Aug 27, 2008 12:05 am Post subject: Re: Bad File Descriptor error |
|
|
On 2008-08-26, Harry <gehariprasath@gmail.com> wrote:
| Quote: |
Dear all,
I am facing a problem with device open and write.
I have written an application in linux on a embedded device running
linux.
I have a printer device interfaced to the processor serial port.
Write() to the device fails at time.perror() shows Bad file descriptor
error. When i printed the file descriptor value, i found it to be 0.
AFAK, file descriptor value of 0 is for stdin.Is that correct?
I am opening the device in Read Write mode with NONBLOCK and NOCTTY
flags.
Any idea of where i may be wrong?
|
Do you check for a negative value when you open the device?
open() and creat() return the new file descriptor, or -1 if an
error occurred (in which case, errno is set appropriately). |
|
| |
|
| Back to top |
Josef Moellers
Guest
|
| Posted: Wed Aug 27, 2008 6:51 am Post subject: Re: Bad File Descriptor error |
|
|
Harry wrote:
| Quote: | Dear all,
I am facing a problem with device open and write.
I have written an application in linux on a embedded device running
linux.
I have a printer device interfaced to the processor serial port.
Write() to the device fails at time.perror() shows Bad file descriptor
error. When i printed the file descriptor value, i found it to be 0.
AFAK, file descriptor value of 0 is for stdin.Is that correct?
|
That is correct. However, there is absolutely nothing special about fd
0, so if you closed all fds and opened a printer device, you'd get fd 0.
| Quote: | I am opening the device in Read Write mode with NONBLOCK and NOCTTY
flags.
Any idea of where i may be wrong?
|
Hard to tell without seeing the code.
From experience (<- my own bugs that hit me  I would say that you
have some program error, e.g. you overwrite the fd with a value of 0
either explicitly ("fd = 0;") or by accident like over-running some array.
If you can "printed the file descriptor value" at some point, you can
print it at other points, so I'd try and print it at various points in
the program, e.g. eimmediately after open()ing and then maybe at the end
of various functions.
I doubt that it's the open() that fails, as that would return an fd of -1.
Josef
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html |
|
| |
|
| Back to top |
Harry
Guest
|
| Posted: Wed Aug 27, 2008 11:54 am Post subject: Re: Bad File Descriptor error |
|
|
I am opening my device in one of the threads in my application. What i
feel is somewhere i might have closed the device with fd=0 which is
the stdin device and so when i open my printer device, my process is
assigned the least available descriptor value,which is what the man
page of open says(man 2 open).
On Aug 27, 11:54 am, Josef Moellers <josef.moell...@fujitsu-
siemens.com> wrote:
| Quote: | Harry wrote:
Dear all,
I am facing a problem with device open and write.
I have written an application in linux on a embedded device running
linux.
I have a printer device interfaced to the processor serial port.
Write() to the device fails at time.perror() shows Bad file descriptor
error. When i printed the file descriptor value, i found it to be 0.
AFAK, file descriptor value of 0 is for stdin.Is that correct?
That is correct. However, there is absolutely nothing special about fd
0, so if you closed all fds and opened a printer device, you'd get fd 0.
I am opening the device in Read Write mode with NONBLOCK and NOCTTY
flags.
Any idea of where i may be wrong?
Hard to tell without seeing the code.
From experience (<- my own bugs that hit me I would say that you
have some program error, e.g. you overwrite the fd with a value of 0
either explicitly ("fd = 0;") or by accident like over-running some array.
If you can "printed the file descriptor value" at some point, you can
print it at other points, so I'd try and print it at various points in
the program, e.g. eimmediately after open()ing and then maybe at the end
of various functions.
I doubt that it's the open() that fails, as that would return an fd of -1..
Josef
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details:http://www.fujitsu-siemens.com/imprint.html |
|
|
| |
|
| Back to top |
Josef Moellers
Guest
|
| Posted: Wed Aug 27, 2008 6:18 pm Post subject: Re: Bad File Descriptor error |
|
|
Harry wrote:
| Quote: | I am opening my device in one of the threads in my application. What i
feel is somewhere i might have closed the device with fd=0 which is
the stdin device and so when i open my printer device, my process is
assigned the least available descriptor value,which is what the man
page of open says(man 2 open).
|
Hmmm, if I read this correctly ("What I feel", "i might have"), what it
says is "I have absolutely no idea what's going on!"
First make sure you know what your program does or doesn't. Then I'd put
in some debugging code and see what that outputs. If you have a daemon()
call in your program (which closes fds 0, 1, 2), you might want to add a
program option which prevents this to see some output of the debugging
code. As an alternative, you could have a global "FILE *trace_output"
which is fopen()ed early in your program and then put in some statements
like "if (trace_output) fprintf(trace_output, "...");".
As it stands, we can just do some more or less educated guesses.
Josef
| Quote: | On Aug 27, 11:54 am, Josef Moellers <josef.moell...@fujitsu-
siemens.com> wrote:
Harry wrote:
Dear all,
I am facing a problem with device open and write.
I have written an application in linux on a embedded device running
linux.
I have a printer device interfaced to the processor serial port.
Write() to the device fails at time.perror() shows Bad file descriptor
error. When i printed the file descriptor value, i found it to be 0.
AFAK, file descriptor value of 0 is for stdin.Is that correct?
That is correct. However, there is absolutely nothing special about fd
0, so if you closed all fds and opened a printer device, you'd get fd 0.
I am opening the device in Read Write mode with NONBLOCK and NOCTTY
flags.
Any idea of where i may be wrong?
Hard to tell without seeing the code.
From experience (<- my own bugs that hit me I would say that you
have some program error, e.g. you overwrite the fd with a value of 0
either explicitly ("fd = 0;") or by accident like over-running some array.
If you can "printed the file descriptor value" at some point, you can
print it at other points, so I'd try and print it at various points in
the program, e.g. eimmediately after open()ing and then maybe at the end
of various functions.
I doubt that it's the open() that fails, as that would return an fd of -1.
Josef
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details:http://www.fujitsu-siemens.com/imprint.html
|
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html |
|
| |
|
| Back to top |
John McCallum
Guest
|
| Posted: Wed Aug 27, 2008 7:39 pm Post subject: Re: Bad File Descriptor error |
|
|
Harry wrote:
| Quote: | What i feel is somewhere i might have closed the device with fd=0
which is the stdin device and so when i open my printer device,
my process is assigned the least available descriptor value,
|
If you have strace on your target, you can check this quite easily. Probably
best to check.
John McCallum |
|
| |
|
| Back to top |
Harry
Guest
|
| Posted: Thu Aug 28, 2008 9:02 am Post subject: Re: Bad File Descriptor error |
|
|
I got my problem solved. I had called close(0) in my code and any
device that was opened after this call was given a file descriptor
value of 0.
Thanks for your support.
By the way, is it the OS that manages thess fd's?
Are the devices stdin,stdout and stderr are opened to all processes in
the system.
On Aug 27, 7:39 pm, John McCallum <john.mccal...@skipthisemerson.com>
wrote:
| Quote: | Harry wrote:
What i feel is somewhere i might have closed the device with fd=0
which is the stdin device and so when i open my printer device,
my process is assigned the least available descriptor value,
If you have strace on your target, you can check this quite easily. Probably
best to check.
John McCallum |
|
|
| |
|
| Back to top |
Jasen Betts
Guest
|
| Posted: Thu Aug 28, 2008 3:49 pm Post subject: Re: Bad File Descriptor error |
|
|
On 2008-08-28, Harry <gehariprasath@gmail.com> wrote:
| Quote: | I got my problem solved. I had called close(0) in my code and any
device that was opened after this call was given a file descriptor
value of 0.
Thanks for your support.
By the way, is it the OS that manages thess fd's?
|
partly.
| Quote: | Are the devices stdin,stdout and stderr are opened to all processes in
the system.
|
no only what's inherited from the parent.
look at the man pages for fork and pipe.
Bye.
Jasen |
|
| |
|
| Back to top |
Josef Moellers
Guest
|
| Posted: Thu Aug 28, 2008 6:36 pm Post subject: Re: Bad File Descriptor error |
|
|
Harry wrote:
| Quote: | I got my problem solved. I had called close(0) in my code and any
device that was opened after this call was given a file descriptor
value of 0.
Thanks for your support.
By the way, is it the OS that manages thess fd's?
|
Yes.
| Quote: | Are the devices stdin,stdout and stderr are opened to all processes in
the system.
|
No.
All fds are inherited from the parent process.
When a new terminal session is started, the terminal is opened either on
fd 0 and dup'ed to fds 1 and 2 or opened on some arbitrary fd and the
dup2'ed to 0, 1 and 2 (fcntl(F_DUPFD may be used for the same purpose).
Josef
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html |
|
| |
|
| Back to top |
Gil Hamilton
Guest
|
| Posted: Fri Aug 29, 2008 8:20 pm Post subject: Re: Bad File Descriptor error |
|
|
Harry <gehariprasath@gmail.com> wrote in
news:5d4091c8-6f67-4d57-ab28-3c9ca17830e6@p10g2000prf.googlegroups.com:
| Quote: | By the way, is it the OS that manages thess fd's?
Are the devices stdin,stdout and stderr are opened to all processes in
the system.
|
To expand a little on what others have already said, stdin, stdout and
stderr may mean several things:
First, file descriptors 0, 1 and 2 are generally known as standard
input, output and error, respectively. But the setup of these file
descriptors is merely a convention provided by the shell. (These are
sometimes abbreviated as "stdin", "stdout" and "stderr".)
Second, the standard C library has since its early days provided a set
of buffered I/O functions that provide wrappers around raw files. The
instances of the data structures for file descriptors 0, 1 and 2 used
with the library functions are named "stdin", "stdout" and "stderr",
respectively. The C runtime startup code sets up the wrapping.
Finally, in linux (but not necessarily other Unix and Unix-like systems)
there are "pseudo-devices" in /dev named stdin, stdout and stderr. If
you investigate you'll see that they are symbolic links to the proc file
system representation of your current file descriptors 0, 1, and 2:
# ls -l /dev/std*
lrwxrwxrwx 1 root root 15 Aug 6 14:59 /dev/stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Aug 6 14:59 /dev/stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Aug 6 14:59 /dev/stdout -> /proc/self/fd/1
They simply provide a handy file name which can be used to refer to the
same file as the respective file descriptors. If you follow further,
you'll see that the /proc/self/fd/? files are themselves symbolic links
that point to the pathname of the file, device or socket to which the
file descriptor is attached. For example, in my shell, they are links
to a pseudo-tty device instance:
# ls -l /proc/self/fd/[012]
lrwx------ 1 root root 64 Aug 29 16:11 /proc/self/fd/0 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 29 16:11 /proc/self/fd/1 -> /dev/pts/1
lrwx------ 1 root root 64 Aug 29 16:11 /proc/self/fd/2 -> /dev/pts/1
(Also note that /proc/self is itself a symbolic link whose content
differs in each process.)
GH |
|
| |
|
| Back to top |
|
