[Bug 1893] New: ICE doesn't deal with replies robustly

[bugzilla-daemon at freedesktop.org]

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   
 
https://bugs.freedesktop.org/show_bug.cgi?id=1893        
   
           Summary: ICE doesn't deal with replies robustly
           Product: xorg
           Version: CVS_head
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Lib/ICE
        AssignedTo: xorg-bugzilla-noise at freedesktop.org
        ReportedBy: daniel at freedesktop.org


This one's sort of difficult to explain, so I'll just quote the patch:
  When two hosts communicate over an ICE connection and use
  different major opcodes for a subprotocol, it is impossible
  to use message replies.

  Let HOST-A and HOST-B be two hosts which communicate over an
  ICE connection and use a subprotocol PROT.  Both have
  obtained an opcode for PROT, HOST-A got the opcode 1 from
  `IceRegisterForProtocolSetup' and HOST-B got the opcode 2
  from `IceRegisterForProtocolReply' (he uses several
  protocols simultaneously, so the value is not 1).

  Now HOST-A sents a message wich requires a reply.  In order
  to do so he sets up an `IceReplyWaitInfo' and calls
  `IceProcessMessages':

      IceReplyWaitInfo  reply_info;
      Bool  reply_ready;

      reply_info.sequence_of_request = IceLastSentSequenceNumber (ice_conn);
      reply_info.major_opcode_of_request = opcode;
      reply_info.minor_opcode_of_request = PROT_Question; 
      reply_info.reply = reply;

      do { 
          IceProcessMessagesStatus  process_status;

          process_status = IceProcessMessages (ice_conn,
                                               &reply_info, &reply_ready);
          ... 
      } while (! reply_ready);

  The `reply_info.major_opcode_of_request' field contains the
  value 1, now.

  Next, HOST-B's reply arrives while HOST-A is executing the
  function `IceProcessMessages'.  Within this function, the
  `reply_wait' is registered via the command

      _IceAddReplyWait (iceConn, replyWait);

  This makes ICE wait for something with major opcode 1.  But
  the variable `header' has `header->majorOpcode == 2',
  because HOST-B sent it this way.  So the following call

          useThisReplyWait = _IceSearchReplyWaits (iceConn, header->majorOpcode);

  (also from `IceProcessMessages') does not find my
  `reply_wait' because ICE searchs for the major opcode 2, not
  1!  I think this is a bug in the ICE library.        
   
   
--         
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email       
   
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.