Errno 9] Bad file descriptor

Discussion in 'Python' started by joblack, Jul 12, 2010.

  1. joblack

    joblack Guest

    I get sometimes a

    Errno 9 Bad file descriptor

    the code is too long to show it here but what are the circumstances
    this could happen? A web search showed nothing.

    I have especially the feeling Python 2.6 has some problems with
    Unicode ... and might not find the file. Is that possible?
     
    joblack, Jul 12, 2010
    #1
    1. Advertising

  2. On Sun, 11 Jul 2010 17:48:40 -0700, joblack wrote:

    > I get sometimes a
    >
    > Errno 9 Bad file descriptor
    >
    > the code is too long to show it here


    You can at least show the actual line that fails. Are you trying to open
    a file, a named socket, a pipe or a device?


    > but what are the circumstances this
    > could happen? A web search showed nothing.


    The first two google hits for "bad file descriptor" seem pretty relevant
    to me:

    http://linux.sys-con.com/node/1053821
    http://lists.freebsd.org/pipermail/freebsd-questions/2003-June/009583.html


    > I have especially the feeling Python 2.6 has some problems with Unicode
    > ... and might not find the file. Is that possible?


    Possible, but you should get

    Errno 2 No such file or directory

    not bad file descriptor.

    If you're trying to open a file, you have a broken file system and need
    to run fsck or equivalent. If it's a pipe or socket or something, you
    need to tell us what it is.



    --
    Steven
     
    Steven D'Aprano, Jul 12, 2010
    #2
    1. Advertising

  3. On 11Jul2010 17:48, joblack <> wrote:
    | I get sometimes a
    |
    | Errno 9 Bad file descriptor
    |
    | the code is too long to show it here but what are the circumstances
    | this could happen? A web search showed nothing.
    |
    | I have especially the feeling Python 2.6 has some problems with
    | Unicode ... and might not find the file. Is that possible?

    You get a UNIX "bad file descriptor" error when you try to use an
    invalid file descriptor number. The typical occasion is when you open a
    file, use it, close it, and then try to continue to use it.

    I would suspect you have performed that sequence in some way.

    But you should really try to produce a small sequence of code that shows
    the error. That way you can post it here, and for extra value you may
    reduce it to the point where you realise what you have done wrong, since
    the failing code is then small enough for you to examine easily.

    Cheers,
    --
    Cameron Simpson <> DoD#743
    http://www.cskk.ezoshosting.com/cs/

    There is a chasm
    of carbon and silicon
    the software can't bridge
    - Haiku Error Messages http://www.salonmagazine.com/21st/chal/1998/02/10chal2.html
     
    Cameron Simpson, Jul 13, 2010
    #3
  4. joblack

    joblack Guest

    Thanks for the answers so far. It's not my code I'm just curious how
    that could happen:

    Starting point:
    ....
    self.status['text'] = 'Processing ...'
    try:
    cli_main(argv)
    except Exception, e:
    self.status['text'] = 'Error: ' + str(e)
    return
    ....
    cli_main:

    keypath, inpath, outpath = argv[1:]
    ....
    with open(inpath, 'rb') as inf:
    serializer = PDFSerializer(inf, keypath)
    with open(outpath, 'wb') as outf:
    filenr = outf.fileno()
    serializer.dump(outf)
    return 0

    PDFSerializer.dump:

    def dump(self, outf):
    self.outf = outf
    ....
     
    joblack, Jul 13, 2010
    #4
  5. joblack

    joblack Guest

    joblack, Jul 14, 2010
    #5
  6. On 13Jul2010 05:56, joblack <> wrote:
    | Thanks for the answers so far. It's not my code I'm just curious how
    | that could happen:
    |
    | Starting point:
    | ...
    | self.status['text'] = 'Processing ...'
    | try:
    | cli_main(argv)
    | except Exception, e:
    | self.status['text'] = 'Error: ' + str(e)
    | return
    | ...
    | cli_main:
    |
    | keypath, inpath, outpath = argv[1:]
    | ...
    | with open(inpath, 'rb') as inf:
    | serializer = PDFSerializer(inf, keypath)
    | with open(outpath, 'wb') as outf:
    | filenr = outf.fileno()
    | serializer.dump(outf)
    | return 0
    |
    | PDFSerializer.dump:
    |
    | def dump(self, outf):
    | self.outf = outf
    | ...


    See that you set serializer.outf to the outf you open in cli_main?
    Any attempt to use serializer _after_ exiting the "with open(outpath,
    'wb') as outf" will use serializer.outf, but the outf is now closed.
    And thus its file descriptor is invalid.

    BTW, by catching Exception in the starting point code you prevent
    yourself seeing exactly which line throws the error. It is usualy a bad
    idea to catch broad things like "Exception". It is normally better to
    place try/except around very small pieces of code and to catch very
    specific things. That way you know exactly what's going wrong and don't
    quietly catch all sorts of unplanned stuff.

    Cheers,
    --
    Cameron Simpson <> DoD#743
    http://www.cskk.ezoshosting.com/cs/

    When buying and selling are controlled by legislation, the first things
    bought and sold are the legislators. - P.J. O'Rourke
     
    Cameron Simpson, Jul 14, 2010
    #6
  7. joblack

    joblack Guest

    > |
    > | Starting point:
    > | ...
    > |         self.status['text'] = 'Processing ...'
    > |         try:
    > |             cli_main(argv)
    > |         except Exception, e:
    > |             self.status['text'] = 'Error: ' + str(e)
    > |             return
    > | ...
    > | cli_main:
    > |
    > |     keypath, inpath, outpath = argv[1:]
    > | ...
    > |     with open(inpath, 'rb') as inf:
    > |         serializer = PDFSerializer(inf, keypath)
    > |         with open(outpath, 'wb') as outf:
    > |             filenr = outf.fileno()
    > |             serializer.dump(outf)
    > |     return 0
    > |
    > | PDFSerializer.dump:
    > |
    > |     def dump(self, outf):
    > |         self.outf = outf
    > | ...
    >
    > See that you set serializer.outf to the outf you open in cli_main?
    > Any attempt to use serializer _after_ exiting the "with open(outpath,
    > 'wb') as outf" will use serializer.outf, but the outf is now closed.
    > And thus itsfiledescriptoris invalid.


    Okay, I changed it to a try: ... finally: block where I open the file
    and in finally I close it. Nothing has changed. The error still
    occures.

    Doesn't the

    with open(outpath, 'wb') as outf:

    clause has to wait until the pdfserialiser.dump method has finished
    anyway? IMHO it can't just call it and immediately close it.

    At least the try: finally: construct should work? Or does it the same
    (call the method and immediately jump to the finally close)?

    Would it work if I would write:

    with closing(outpath, 'wb') as outf: ?

    I'm a little bit confused about Python's strange processing ...
     
    joblack, Jul 14, 2010
    #7
  8. On 07/14/2010 01:21 PM, joblack wrote:
    >> |
    >> | Starting point:
    >> | ...
    >> | self.status['text'] = 'Processing ...'
    >> | try:
    >> | cli_main(argv)
    >> | except Exception, e:
    >> | self.status['text'] = 'Error: ' + str(e)
    >> | return
    >> | ...
    >> | cli_main:
    >> |
    >> | keypath, inpath, outpath = argv[1:]
    >> | ...
    >> | with open(inpath, 'rb') as inf:
    >> | serializer = PDFSerializer(inf, keypath)
    >> | with open(outpath, 'wb') as outf:
    >> | filenr = outf.fileno()
    >> | serializer.dump(outf)
    >> | return 0
    >> |
    >> | PDFSerializer.dump:
    >> |
    >> | def dump(self, outf):
    >> | self.outf = outf
    >> | ...
    >>
    >> See that you set serializer.outf to the outf you open in cli_main?
    >> Any attempt to use serializer _after_ exiting the "with open(outpath,
    >> 'wb') as outf" will use serializer.outf, but the outf is now closed.
    >> And thus itsfiledescriptoris invalid.

    >
    > Okay, I changed it to a try: ... finally: block where I open the file
    > and in finally I close it. Nothing has changed. The error still
    > occures.


    Where does the error occur? If Cameron is right, it occurs somewhere
    completely different, when serializer.dump() is already long done, when
    some unsuspecting fool tries to do something with serializer.outf (such
    as closing it)

    >
    > Doesn't the
    >
    > with open(outpath, 'wb') as outf:
    >
    > clause has to wait until the pdfserialiser.dump method has finished
    > anyway? IMHO it can't just call it and immediately close it.
    >
    > At least the try: finally: construct should work? Or does it the same
    > (call the method and immediately jump to the finally close)?
    >
    > Would it work if I would write:
    >
    > with closing(outpath, 'wb') as outf: ?
    >
    > I'm a little bit confused about Python's strange processing ...
     
    Thomas Jollans, Jul 14, 2010
    #8
  9. joblack

    joblack Guest

    > Where does the error occur? If Cameron is right, it occurs somewhere
    > completely different, when serializer.dump() is already long done, when
    > some unsuspecting fool tries to do something with serializer.outf (such
    > as closing it)

    I have found it but still I don't get it.

    Dump looks like this:

    ....

    File "C: ... ineptpdf8.4.20.pyw", line 1266, in initialize return
    self.initialize_fopn(docid, param)
    File "C: ... ineptpdf8.4.20.pyw", line 1411, in initialize_fopn print
    buildurl

    IOError: [Errno 9] Bad file descriptor

    Two strange things:

    1st: in the buildurl is only the url (as a string) to open (something
    like http://www.serverblaba.com/asdfasdf?wdfasdf=4&awfwf=34 ...)
    2nd: it works if I start in in IDLE, it doesn't work if I double klick
    on the .pyw file.

    How can printing out a string throw a IOError exception? I'm quite
    puzzled.
     
    joblack, Jul 16, 2010
    #9
  10. joblack

    MRAB Guest

    joblack wrote:
    >> Where does the error occur? If Cameron is right, it occurs somewhere
    >> completely different, when serializer.dump() is already long done, when
    >> some unsuspecting fool tries to do something with serializer.outf (such
    >> as closing it)

    > I have found it but still I don't get it.
    >
    > Dump looks like this:
    >
    > ...
    >
    > File "C: ... ineptpdf8.4.20.pyw", line 1266, in initialize return
    > self.initialize_fopn(docid, param)
    > File "C: ... ineptpdf8.4.20.pyw", line 1411, in initialize_fopn print
    > buildurl
    >
    > IOError: [Errno 9] Bad file descriptor
    >
    > Two strange things:
    >
    > 1st: in the buildurl is only the url (as a string) to open (something
    > like http://www.serverblaba.com/asdfasdf?wdfasdf=4&awfwf=34 ...)
    > 2nd: it works if I start in in IDLE, it doesn't work if I double klick
    > on the .pyw file.
    >
    > How can printing out a string throw a IOError exception? I'm quite
    > puzzled.


    The extension .pyw says to run the script without opening a console
    window. If there's no console, the script can't print to it. Result?
    IOError exception.
     
    MRAB, Jul 16, 2010
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    9
    Views:
    759
    Abhijit Soman
    Jan 6, 2005
  2. Vishnu
    Replies:
    0
    Views:
    528
    Vishnu
    Jan 6, 2005
  3. rbt
    Replies:
    4
    Views:
    1,057
  4. Simon Strandgaard
    Replies:
    4
    Views:
    650
    Simon Strandgaard
    Feb 16, 2004
  5. Valerie Hollingsworth

    Bad file descriptor - connect(2) (Errno::EBADF)

    Valerie Hollingsworth, May 9, 2008, in forum: Ruby
    Replies:
    0
    Views:
    656
    Valerie Hollingsworth
    May 9, 2008
Loading...

Share This Page