Problem with thread, socket and HP-UX 11.00

[Sergio Abrami]

Hi all,
on a L1000 with HP-UX 11.00, some application running on threads (pthreads) using socket (TCP) and accept() is not working.
The behaviour is the following:
- the remote client connects and connect() is successfull;
- netstat says the connection is ESTABLISHED
- the application accept() returns -1 and errno is usually 9 (but sometimes is 0);
- the client stays connected but the thread on the server that made the accept() can't continue;
- with applications not based on threads, accept() works correctly (this should exclude resource problems like maxfiles...);
- if I compile a test program (server.c attached) and run the routine making the accept() in the main part, it works but if it runs in a new thread, the problem arises.

Furthermore:
- The problems arises with different applications;
- I suspect the problem is related to PHKL_20202 (Fix pthread error return, nfs/tcp panic) but it is not supersed nor have any kind of warnings

Please find attached:

- kernel parameters
- swlist -l product
- server and client test programs
(Compiled:
client: cc client.c -o client
server multi-thread: cc server.c -lpthread -D_PTHREAD -o server.mt
server mono-thread: cc server.c -o server.st
)

Can anyone help?
Thanks,
Sergio

[rick jones]

I've not looked at the attachemnt (not having an unzip utility on my box at present) but you might want to run tusc against your application (include the lwpid option and make sure that indeed when threaded, your application is calling accept() with the proper file descriptor. Perhaps there are some synchronization issues in the application.

Also, IIRC, to compile threaded on UX, one definces -D_REENTRANT, I do not recall a -D_PTHREAD define being used. I'm guessing that is one you are using in your source, but I don't think the header files will look for that...

[Sergio Abrami]

Thanks Rick,
I'll use tusc and let you know
Sergio

[James Murtagh]

Hi Sergio,

Just FYI, I compiled your programs on 11i and both the single and multi threaded versions worked fine. Unfortunately I don't have access to any 11.00 boxes here so I couldn't test further. Your patches look up to date.

As mentioned, I used the same compile options as yourself but from the pthread man page :

"A multi-threaded application must define the appropriate POSIX
revision level (199506) at compile time and link against the pthread
library via -lpthread. For example:

cc -D_POSIX_C_SOURCE=199506L -o myapp myapp.c -lpthread"

Not sure if this is relevant. Tusc is certainly the tool to use here. Useful options would be :

-p : show pids
-v : verbose
-f : follow forks
-u : print lwpids
-l : print user pthread ids

Regards,

James.

[Sergio Abrami]

Thanks, James!!!
Your help is much appreciated.
Sergio

[Massimo Bianchi]

Hi Sergio,
i see, from tusc, that there are more errors coming first:

open("/opt/graphics/OpenGL/lib/libogltls.sl", O_RDONLY, 0) ERR#2 ENOENT

mmap(NULL, 1232896, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_SHLIB, 3, 0x47000) ERR#12 ENOMEM

accept(3, 0x779bb0c8, 0x779bb0bc) ............. ERR#9 EBADF

It may worth to resolve the first... maybe the last is only a consequence.

HTH,
Massimo

[Sergio Abrami]

Massimo,
we tried tusc on another box were everything works fine and we get the same first error messages.
So I think they should be considered irrelevant as far as the last one is concerned...

Sergio

[James Murtagh]

Hi Sergio,

I can confirm those two other messages are not applicable here.

This looks strange....I just ran it on an 11.00 workstation and the multi-threaded worked fine. The single threaded one actually had problems??

In any case it looks like a software issue. I think you need to review your patching, I suspect a missing dependency to the ARPA code you have. You can use swverify or even better use /usr/contrib/bin/check_patches if you have it. Or you could manually check the main suspects, ARPA and possibly Streams too. Let me know if you have any questions regarding this procedure.

Regards,

James.

[Sergio Abrami]

Thanks,
please find attached the swverify.log file.
Can you find anything strange?
Sergio

[Massimo Bianchi]

Hi Sergio,
i don't that is relevatn, but there is a warning about a product for another OS.


I think it is this:

PPM_030102.PPMFILES,l=/,r=3.1.2,a=S700/S800_HPUX_10.20,v=Marconi


Do you know what is it ?


Good luck !
Massimo

[Sergio Abrami]

Forgive me,
I should have told you before...

For sure it is irrelevant

Ciao Max!!!!

[James Murtagh]

Hi Sergio,

Its actually the swagent.log we need to have a look at. Looks like its gonna be big though....it may be worth starting with the swverify of your arpa patch first but feel free to post the full thing.

Regards,

James.

[Sergio Abrami]

Hi James,
please find attached swagent.log.

Best regards,
Sergio

[James Murtagh · Accepted solution]

Hi Sergio,

I couldn't see too much wrong in the swagent.log, but when I re-visited your patch list I did notice something I really should of at the start. You present ARPA patch is PHNE_24715 which is very close to the dreaded PHNE_23456. It has two critical patch warnings against it, basically saying that the server side of a tcp/ip connection can lose data from the client in certain circumstances. See the patch text on the ITRC for a full description.

I would advise you install the latest, recommended ARPA patch, PHNE_28538. This will also update your Streams code etc.

Regards,

James.

[Sergio Abrami]

James,
I'll leave your post "unassigned" until I'll install the patch.
This because most probably this is the "magical answer"...

Regards,
Sergio

[Sergio Abrami]

Yes James,
it was the answer that solved the problem.
By installing that patch and all dependencies we eventually solved the problem.
Thanks a lot,
Sergio