sendmsg() API

[Shweta_3]

Hello,

I want to know all the known defects relating to the sendmsg() socket API.

I am using a multi-threaded application which uses sendmsg(), and on two different machines I am seeing different issues (different patch levels)

a) sendmsg() API cores and when using debugger (gdb) on the application we see that errno is set to EPIPE.

b) sendmsg() returns -1, however the errno value it gives is zero. perror prints an error but it looks unreliable.

Could somebody guide me as to how should I know which patches I should apply and if there are any known bugs for sendmsg() API on HP.

Thanks,
Shweta

[Arunvijai_4 · Accepted solution]

Hi Shweta,

You can find more information here, PHNE_33628

http://www2.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHNE_33628&context=hpux:800:11:11

-Arun

[Arunvijai_4]

Hi Again,

When using AF_UNIX sockets blocking sendmsg()
returns EMSGSIZE when receive side is
close to being full. This can happen on blocking or
non-blocking.
( SR:8606134574 CR:JAGad03709 )

( SR:8606401226 CR:JAGaf61175 )
Due to race condition between close(2) and sendmsg(2)
system calls, when sending ancillary data, system can
panic with DPF.

-Arun

[Muthukumar_5]

which os you are using? uname -r will give that.

Search here,

http://www1.itrc.hp.com/service/patch/search.do?BC=patch.breadcrumb.main|&pageContextName=hpux:::

with your operating system and sendmsg keyword.

--
Muthu

[Muthukumar_5]

Read this,

[EPIPE] and SIGPIPE signal
An attempt was made to send on a socket
that was connected, but the connection has
been shut down, either by the remote peer
or by this side of the connection. Note
that the default action for SIGPIPE, unless
the process has established a signal
handler for this signal, is to terminate
the process.

Remote peer is closing socket connection while sending message. May be a problem with network or programming too.

--
Muthu

[Shweta_3]

I downloaded a lot of patches and patched up my system. However the bahavior of the sendmsg() API has not changed for me. I am not sure where is the problem.

[rick jones]

If after patching behaviour has not changed, it may suggest some issues in the application.

I think the EPIPE has been discussed - it suggests that the app tried to send on a closed connection. That you get EPIPE in the debugger and probably a core dump outside of it? stems from debuggers tending to intercept signals.

The errno being zero could be the application making some other call that sets errno between the time sendmsg has failed and when the errno is printed.

FWIW, are you compiling -D_REENTRANT and linking with -lpthread?

[Arunvijai_4]

Hi Shweta,

To dig further, you can use "tusc" to find out what all the calls being made and where it was stuck. You can download "tusc" from,

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.8/

-Arun

[Shweta_3]

Rick,

Thanks a lot. The -D_REENTRANT flag did it. All the time I was under the assumption that by default the renetrant mode is set. Now I feel silly about it.

Thank You once again.

Shweta