dup(0) failed after 3195 successes: Bad file descriptor

Started by CSNalmost 22 years ago5 messagesgeneral
Jump to latest
#1CSN
cool_screen_name90001@yahoo.com

At startup this appears in the log:

WARNING: dup(0) failed after 3195 successes: Bad file
descriptor

What does it mean?

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: CSN (#1)
Re: dup(0) failed after 3195 successes: Bad file descriptor

CSN <cool_screen_name90001@yahoo.com> writes:

WARNING: dup(0) failed after 3195 successes: Bad file
descriptor

Hmm. What system is this on? What errno code corresponds to
"Bad file descriptor"?

This is coming from

thisfd = dup(0);
if (thisfd < 0)
{
/* Expect EMFILE or ENFILE, else it's fishy */
if (errno != EMFILE && errno != ENFILE)
elog(WARNING, "dup(0) failed after %d successes: %m", used);
break;
}

I would suppose there is another EXXX code we have to allow to pass
without comment, but I don't know from your report what it is.

regards, tom lane

#3CSN
cool_screen_name90001@yahoo.com
In reply to: Tom Lane (#2)
Re: dup(0) failed after 3195 successes: Bad file descriptor
--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

CSN <cool_screen_name90001@yahoo.com> writes:

WARNING: dup(0) failed after 3195 successes: Bad

file

descriptor

Hmm. What system is this on? What errno code
corresponds to
"Bad file descriptor"?

This is coming from

thisfd = dup(0);
if (thisfd < 0)
{
/* Expect EMFILE or ENFILE, else it's
fishy */
if (errno != EMFILE && errno != ENFILE)
elog(WARNING, "dup(0) failed after
%d successes: %m", used);
break;
}

I would suppose there is another EXXX code we have
to allow to pass
without comment, but I don't know from your report
what it is.

It's on windows xp home edition. I just upgraded
cygwin and postgresql to 7.4.3 - the warning didn't
appear in the log previously.

CSN

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

#4Martijn van Oosterhout
kleptog@svana.org
In reply to: Tom Lane (#2)
Re: dup(0) failed after 3195 successes: Bad file descriptor

On Tue, Jun 29, 2004 at 10:10:18AM -0400, Tom Lane wrote:

CSN <cool_screen_name90001@yahoo.com> writes:

WARNING: dup(0) failed after 3195 successes: Bad file
descriptor

Hmm. What system is this on? What errno code corresponds to
"Bad file descriptor"?

That would be EBADF I think. However, my linux manpage indicates it's
not a possible return from dup, only from dup2. Very odd.

--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Show quoted text

Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Martijn van Oosterhout (#4)
Re: dup(0) failed after 3195 successes: Bad file descriptor

Martijn van Oosterhout <kleptog@svana.org> writes:

On Tue, Jun 29, 2004 at 10:10:18AM -0400, Tom Lane wrote:

Hmm. What system is this on? What errno code corresponds to
"Bad file descriptor"?

That would be EBADF I think. However, my linux manpage indicates it's
not a possible return from dup, only from dup2. Very odd.

HPUX man page says that it's a valid dup() error when the *supplied*
descriptor is bogus. Which is surely not true for zero (stdin) and
is even less plausible given that the previous 3195 iterations of this
tight loop had no problem with the same supplied descriptor.

But CSN says in a followup that this is on Cygwin. In short, what we
got here is another Cygwin bug [yawn]. I'm inclined to do something
like

if (thisfd < 0)
{
/*
* Expect EMFILE or ENFILE, else it's fishy; and Cygwin has
* a fishiness level all of its own...
*/
if (errno != EMFILE && errno != ENFILE
#ifdef __CYGWIN__
&& errno != EBADF
#endif
)
elog(WARNING, "dup(0) failed after %d successes: %m", used);
break;
}

unless someone can point to another platform that does the same thing.
(Hey -win32 hackers: does the native port exhibit this behavior?)

regards, tom lane