Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Errno 9] Bad file descriptor

Reply
Thread Tools

Errno 9] Bad file descriptor

 
 
joblack
Guest
Posts: n/a
 
      07-12-2010
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?
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-12-2010
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/f...ne/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
 
Reply With Quote
 
 
 
 
Cameron Simpson
Guest
Posts: n/a
 
      07-13-2010
On 11Jul2010 17:48, joblack <(E-Mail Removed)> 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 <(E-Mail Removed)> 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/ch...2/10chal2.html
 
Reply With Quote
 
joblack
Guest
Posts: n/a
 
      07-13-2010
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
....
 
Reply With Quote
 
joblack
Guest
Posts: n/a
 
      07-13-2010
All right I found the web link. It's an improvement to the pdf miner
project (adds pdf dump methods).

http://pastebin.com/P8SWj5YK

 
Reply With Quote
 
Cameron Simpson
Guest
Posts: n/a
 
      07-14-2010
On 13Jul2010 05:56, joblack <(E-Mail Removed)> 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 <(E-Mail Removed)> 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
 
Reply With Quote
 
joblack
Guest
Posts: n/a
 
      07-14-2010
> |
> | 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 ...
 
Reply With Quote
 
Thomas Jollans
Guest
Posts: n/a
 
      07-14-2010
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 ...


 
Reply With Quote
 
joblack
Guest
Posts: n/a
 
      07-15-2010
> 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.
 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      07-16-2010
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
errno 22 instead of errno 2 Glenn Linderman Python 0 01-28-2009 07:52 AM
&errno, sizeof errno viza C Programming 20 09-14-2008 09:53 PM
Bad file descriptor - connect(2) (Errno::EBADF) Valerie Hollingsworth Ruby 0 05-09-2008 05:39 PM
[Errno 9] Bad File Descriptor on Windows 2003 Server & Py 2.4.1 rbt Python 4 05-03-2005 05:13 PM
`close': Bad file descriptor - filename (Errno::EBADF) Simon Strandgaard Ruby 4 02-16-2004 10:04 PM



Advertisments