Red Hat Bugzilla – Bug 65880
multithreaded clnt_call failure on RH7.2
Last modified: 2006-02-21 13:49:00 EST
Description of Problem:
I have a multi-threaded client, in which I create CLIENT handle in the first
thread, and then use clnt_call() in secondary thread to access server. clnt_call
() return failure.
If the clnt_create() and clnt_call() are invoked in the same thread then
clnt_call() returns success.
On Linux RH7.1 there is no problem. but it's giving problem on RH7.2 (kernel
level- 2.4.9-31 - i586).
Version-Release number of selected component (if applicable):
The problem is reproducible in a simple multi threaded RPC program.
I am attaching new.tar file. Just run compile script to compile the programs.
Steps to Reproduce:
1. run "compile" - to compile the sample.
2. run "dateproc & " - to run the RPC server
3. run "rdate hostname" - to run the client. (Hostname must be the machine name
where the dateproc server is running.
clnt_call() Returns Failure.
It should return SUCCESS.
Here is the results when I run the sample:
[no-view] KONDAR@tintin> dateproc &
[no-view] KONDAR@tintin> rdate tintin
Before clnt_create in main thread
clnt_call failed at date_clnt.c
tintin: RPC: Can't encode arguments
time on host tintin = 1023127658
time on host tintin = Mon Jun 3 23:37:38 2002
Created attachment 59405 [details]
This file is a tar file and it contains the sample to reproduce the problem
Older glibc's didn't support multithreaded RPC properly.
In recent glibc's, each thread has its own RPC state, so you have to clnt_create
in the thread you want to use it.
Is there any alternative way to use CLIENT handle created in other threads ?
Basically, In my application I create CLIENT handle in main thread and keep on
calling clnt_call() in secondary thread in regular interval. This is to make
sure that the server is alive.
It would be nice if you could suggest something here. I am really stuck with
If that is the case, how it is working fine with RedHat 7.1 ?
My application is huge one and I am just porting it from Redhat 7.1 to 7.2 and
I hit this problem.
*** This bug has been marked as a duplicate of 65544 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.