home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / vms / 14806 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  3.6 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!hplabs!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Need help with UNASEFC
  5. Message-ID: <9209091633.AA08765@uu3.psi.com>
  6. Date: 9 Sep 92 16:30:42 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 66
  11.  
  12.  
  13.     I have a very simple client-server pair of programs with a bizarre
  14.     bug.
  15.  
  16.     The server reads a big file into memory, listens for queries on a
  17.     mailbox (using SYS$QIOW), and responds by writing back to the client's
  18.     mailbox.
  19.  
  20.     The client sends queries to the server's mailbox and reads the
  21.     reponses back on its own mailbox (again, using SYS$QIOW).
  22.  
  23.     Everything works great.  I modified the server to use SYS$CRMPSC to
  24.     map the big file into memory rather than reading it all in at the
  25.     beginning.  I've stepped through with the debugger, and everything
  26.     works as expected.  All system service return values come back with
  27.     SUCCESS.
  28.  
  29.     However, the client (which has not been changed) often chokes and dies
  30.     when it tries to read the response.  The QIOW status is UNASEFC
  31.     (unassociated event flag cluster), but the IOSB status is SUCCESS and
  32.     the transfer count is correct.  It seems to happen only when the
  33.     server has to touch one of the mapped pages for the first time.  If
  34.     the client is run again immediately with the same query, the response
  35.     comes back just fine.
  36.  
  37.     Neither program relies on event flags since they're using QIO rather
  38.     than QIOW, so they both specify 0 as the event flag number.  Thus they
  39.     aren't even trying to use event flags in a common event flag cluster
  40.     (there are no other references to event flags in either program).
  41.  
  42. It's impossible to tell for sure, but I'll make a guess:  Check your SYS$QIOW
  43. call and make sure you are passing it by value, NOT by reference.  Since so
  44. many values in VMS are passed by reference, it's easy to get this wrong and
  45. use &0 instead of just 0.  The result would be pretty much what you see:  VMS
  46. only uses the low order byte of the value passed to determine the event flag
  47. number; it ignores the extra high-order bits.  If you pass an address, you are
  48. really specifying some arbitrary event flag.  If it happens to be in cluster 2
  49. or 3 (50% chance), the common event flag range, UNASEFC is the likely result.
  50. The other half of the time, some random local event flag gets used, and
  51. eventually set when the operation completes.  In most cases, this will have
  52. no visible effects on the program.  Note that an argument like &0 is likely
  53. to be passed as the address of a zero pushes onto the stack, so that even
  54. multiple calls from the same line of code may produce different effects at
  55. run time.  Totally unconnected changes to the path the code follows could
  56. change the address passed.
  57.  
  58. BTW, a failure status from the QIO[W] call itself means that the error was
  59. detected before the I/O was ever started.  Any later problems are reported in
  60. the IOSB status field.  The success status and correct length you are seeing
  61. in the IOSB are left over from the last successful use of the IOSB - SYS$QIO
  62. won't clear the IOSB unless it can successfully queue the request.
  63.  
  64.     Just to add more confusion, when the client program sees the
  65.     non-success status returned from QIOW, it calls exit() (VAX C RTL)
  66.     with that status.  The client then dies with an access violation
  67.     inside exit().  When running with the debugger, things get really
  68.     hosed up, and I get all these messages about internal DEBUG coding
  69.     errors.
  70.  
  71. This sounds as if you are writing garbage into the stack, perhaps in error
  72. recovery code that had previously never been exercised.
  73.  
  74.     Any clues out there?  (VMS V5.5, VAX C V3.2)
  75.  
  76.                             -- Jerry
  77.  
  78.