Hi All,

I am crossposting to networking-discuss and tools-compilers because I am not 
sure if this is a compiler issue or a bug in the rpc module:

While chasing another issue related to the RPC connection manager, I noticed 
that on my x64 development box, tuning rpcmod:clnt_max_conns had no effect. 
Irrespective of which value I set it to, the RPC client would only open one 
connection. I could not observe this issue on a Solaris8 SPARC machine.

This issue kept me busy for a day (me questioning my understanding of the 
code), 
until I finally inspected the assembler code of the function in question. 
Here's 
an annotated piece of code (from connmgr_get in uts/common/rpc/clnt_cots.c), 
disassembled with mdb:

    1863                /*
    1864                 * If we are at the maximum number of connections to
    1865                 * the server, hand back the least recently used one.
    1866                 */
    1867                if (i == clnt_max_conns) {

connmgr_get+0x2c4:              cmpl   $0x1,%ebx
connmgr_get+0x2c7:              jle    +0xbe    <connmgr_get+0x38b>

Apparently, the compiler has optimized

     463 #define        CLNT_MAX_CONNS  1       /* concurrent connections 
between clnt/srvr */
     464 static int clnt_max_conns = CLNT_MAX_CONNS;

into a constant value of 1 for clnt_max_conns.

When I recompiled rpcmod with clnt_max_conns declared as int (without static), 
the issue was fixed, and assembler code looked OK:

connmgr_get+0x2c4:              movl   +0x47dae5e(%rip),%eax    <clnt_max_conns>
connmgr_get+0x2ca:              cmpl   %eax,%ebx
connmgr_get+0x2cc:              jle    +0xbe    <connmgr_get+0x390>


My question is: Is this a compiler issue or a genuine bug?

Due to various other constraints, I used my antique snv_98 onnv bldenv with 
spro 
11 (cc: Sun C 5.8 Patch 121016-05 2007/01/10).

Any pointers are highly appreciated. If this is not a compiler bug, I'd open a 
bug and prepare a webrev with the fix. If this issue is fixed with current 
compilers, I apologize for the noise.

Cheers,

Nils

Reply via email to