bill@cs.columbia.edu (Bill Schilit) (11/11/90)
Hi, I am getting messages rejected from a MIG generated xxx_server() with return code MIG_BAD_ARGUMENTS. The cause appears to be differences in the msg_type_t fields of the incoming message and the msg_type_t field of the MIG generated static Check structure. The differing field is msg_type_deallocate which the static Check structure wants to be TRUE but the message says is FALSE. The client side *is* setting the bit to TRUE. I can run the interface locally on one machine and it works fine, but between two hosts it breaks. I found a suspicious comment in netmsgserver (ipc_in.c) that says: * 2-Jan-87 Robert Sansom (rds) at Carnegie Mellon University * Minor changes to integrate with other modules. * Always set deallocate bit to FALSE. There are two types of checks in mig generated code, so I will try setting -DUseStaticMsgType=0 which uses a field by field comparison of msg_type_t and skips the msg_type_deallocate field (!). However I'm still wondering what the story is and if anyone else has seen this problem... - Bill
Richard.Draves@CS.CMU.EDU (11/13/90)
> Excerpts from netnews.comp.os.mach: 11-Nov-90 MIG+netmsgserver bug? Bill > Schilit@cs.columbia (1054) > I am getting messages rejected from a MIG generated xxx_server() with > return code MIG_BAD_ARGUMENTS. The cause appears to be differences in > the msg_type_t fields of the incoming message and the msg_type_t field > of the MIG generated static Check structure. The differing field is > msg_type_deallocate which the static Check structure wants to be TRUE > but the message says is FALSE. The client side *is* setting the bit > to TRUE. This isn't really the netmsgserver's bug, although it is exacerbating the situation. The problem is that the Mach 2.5 interface doesn't specify the state of the deallocate bit in a received message. The kernel passes the deallocate bit through unchanged, and the quick type-checking code in Mig relies on this. To work around the problem, you can use a msg_type_long_t (IsLong specifier in Mig) for that argument, or turn off quick type-checking for the entire module. The Mach 3.0 interface specifies that the deallocate bit in a received message is TRUE for out-of-line memory and FALSE otherwise, so this isn't a problem. Rich
Robert.Sansom@CS.CMU.EDU (11/13/90)
As Rich Draves said, this is not the fault of the netmsgserver. The root of the problem is that the msg_type_deallocate field should not be part of the type description for something in the message. It is really just an indication to the LOCAL kernel that the data should be deallocated from the sending task's address space. Since the netmsgserver does not want this to happen, it sets the deallocate bit to FALSE (as the comment says---the comment should have said "Always set deallocate bit to FALSE so that we don't accidentally deallocate parts of our address space." or something to that effect). Robert Sansom, School of Computer Science Carnegie Mellon University, Pittsburgh, PA 15213 INTERNET: sansom@cs.cmu.edu CSNET: sansom%cs.cmu.edu@relay.cs.net BITNET: sansom%cs.cmu.edu@cmuccvma UUCP: ...!seismo!cs.cmu.edu!sansom