[q] Bad address in recv().

[Athanasopoulos Elias]

Hi,

I am developing a network application in Linux. When my client connects
to a server, although connect() succesfully returns a valid file
descriptor, I'm failing to receive any data. I use recv() and the
returing error is 'Bad Address'. Before I use recv() I check for
incoming data with the FIONREAD ioctl. The latter shows that *there
are* data to be read from the socket.

I checked recv()'s manual page, and I couldn't find any info about
the 'Bad Address' error message.

Any hints would be appreciated.

Thanks in advance,
Elias

--
Elias Athanasopoulos | I bet the human brain is | H.E.P & Apps. Lab.
http://www.uoa.gr/~eatha | a kludge. -Marvin Minsky | University Of Athens

[John Gordon]

Athanasopoulos Elias <ea...@nikias.cc.uoa.gr> writes:

> I checked recv()'s manual page, and I couldn't find any info about
> the 'Bad Address' error message.

> Any hints would be appreciated.

perhaps the "bad address" is the address of the buffer you're passing
to recv() to hold the received data. (although i looked at the man page
for recv() on my system, and EFAULT isn't listed.)

---
"... What with you being his parents and all, I think that you could
be trusted not to shaft him." -- Robert Chang, rec.games.board

John Gordon gor...@osiris.cso.uiuc.edu

[David Rubin]

Athanasopoulos Elias wrote:

> I checked recv()'s manual page, and I couldn't find any info about
> the 'Bad Address' error message.

As John points out, the message refers to the address of the receive buffer.
Perhaps you have an uninitialized pointer?

From recv(2) Linux Programmer's Manual:
EFAULT The receive buffer pointer(s) point outside the
process's address space.

david

--
FORTRAN was the language of choice
for the same reason that three-legged races are popular.
-- Ken Thompson, "Reflections on Trusting Trust"

[Athanasopoulos Elias]

On Wed, 21 Feb 2001, John Gordon wrote:

> perhaps the "bad address" is the address of the buffer you're passing
> to recv() to hold the received data. (although i looked at the man page
> for recv() on my system, and EFAULT isn't listed.)

John, David you were both right. I hadn't initialized the buffer
I was passing to recv().

Thank you, both, for the quick answer! :-)

Regards,

[Nate Eldredge]

David Rubin <dlr...@hotmail.com> writes:

> Athanasopoulos Elias wrote:
>
> > I checked recv()'s manual page, and I couldn't find any info about
> > the 'Bad Address' error message.
>
> As John points out, the message refers to the address of the receive buffer.
> Perhaps you have an uninitialized pointer?
>
> From recv(2) Linux Programmer's Manual:
> EFAULT The receive buffer pointer(s) point outside the
> process's address space.

In fact, EFAULT from a system call should be treated the same as
SIGSEGV: your program has a bug, fix it. It's unfortunate that it's
not as noticeable. (Apparently there are systems that will actually
raise SIGSEGV when an invalid address is passed to a system call,
rather than returning EFAULT.)

--

Nate Eldredge
neld...@hmc.edu

[Andrew Gierth]

>>>>> "Nate" == Nate Eldredge <neld...@hmc.edu> writes:

Nate> In fact, EFAULT from a system call should be treated the same
Nate> as SIGSEGV: your program has a bug, fix it.

There is one exception to this. If you use an mmap() region as a
parameter to a system call (e.g. using the mmap/write method of
copying a file), a pagein error on the mmap region will typically
result in an EFAULT return.

(This can lead to nonintuitive behaviour, such as cp or cat displaying
a "bad address" error when an I/O error occurs on the source file.)

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>