tags:

views:

64

answers:

3

I am writing client/server programs on Unix in C, using send/recv. I am occasionally getting a segmentation fault from a recv call. The behavior is not perfectly reproducible; sometimes it happens, and sometimes the program runs to completion.

Any ideas what this could mean?

+4  A: 

If the segmentation fault is in the recv() call itself, then that implies that the buffer you passed to recv() is not properly allocated or is not the size that you told recv() it was.

caf
Hmm...but why would it not be 100% reproducible?
Because invoking undefined behavior does not give reproducible results. Just listen to caf's advice and fix the incorrect size or memory-corruption bugs in your code.
R..
@User432944: All that means is that sometimes the overlap happened to go into a page your process doesn't own, and other times it just stomped across a random bit of memory you do own.
caf
+1  A: 

Well, it usually means you're receiving more data than your buffer has allowed for.

For example, if you malloc 20 bytes and recv 1000 bytes, you'll run into this problem.

Unfortunately, without seeing the code, and without some very rapid advances in the field of psychic debugging, we'll never know for sure *a.


*a That's a subtle hint to post the code, by the way :-)

paxdiablo
+1 subtlety, almost subliminal
msw
So subtle I almost missed it.
Matt Joiner
A: 

this could also mean that the socket on the other side is closed before you write to it. that is a SIGPIPE that may be causing ur application to close.

user123
That's not quite true, a SIGPIPE is not the same as a segmentation fault. Also, he mentioned that it is problematic on the `recv` call.
dreamlax
SIGPIPE doesn't cause a segmentation fault; it just exits. Also, the SIGPIPE would occur on the writing side when there's no receiver, but that doesn't apply to `recv()` - it might apply to `send()`.
Jonathan Leffler