Bad File Descriptor error - Linux

This is a discussion on Bad File Descriptor error - Linux ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Bad File Descriptor error

  1. 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?

  2. Re: Bad File Descriptor error

    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

  3. 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 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



  4. Re: Bad File Descriptor error

    Harry wrote:
    > 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

    > On Aug 27, 11:54 am, Josef Moellers > 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

  5. Re: Bad File Descriptor error

    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


  6. 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
    wrote:
    > 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



  7. Re: Bad File Descriptor error

    On 2008-08-28, Harry wrote:
    > 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.

    > 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

  8. Re: Bad File Descriptor error

    Harry wrote:
    > 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.

    > 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

  9. Re: Bad File Descriptor error

    Harry wrote in
    news:5d4091c8-6f67-4d57-ab28-3c9ca17830e6@p10g2000prf.googlegroups.com:

    > 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

+ Reply to Thread