Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!+ From: Richard.Draves@CS.CMU.EDU Newsgroups: comp.os.mach Subject: Re: MIG+netmsgserver bug? Message-ID: Date: 12 Nov 90 16:52:42 GMT References: <9011110250.AA29362@cs.columbia.edu> Organization: Carnegie Mellon, Pittsburgh, PA Lines: 26 In-Reply-To: <9011110250.AA29362@cs.columbia.edu> > 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