Errno 9] Bad file descriptor

J

joblack

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?
 
S

Steven D'Aprano

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

Cameron Simpson

| 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 <[email protected]> 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
 
J

joblack

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

Cameron Simpson

| 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 <[email protected]> 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
 
J

joblack

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

Thomas Jollans

|
| 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)
 
J

joblack

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

MRAB

joblack said:
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top