home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / mswindo / programm / misc / 1290 < prev    next >
Encoding:
Text File  |  1992-08-12  |  2.0 KB  |  48 lines
  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!ods!scott
  3. From: scott@ods.com (Scott Harper)
  4. Subject: DLL trashing App's Data Segment?
  5. Message-ID: <1992Aug12.145332.24382@ods.com>
  6. Organization: Optical Data Systems, Inc.
  7. X-Newsreader: Tin 1.1 PL3
  8. Date: Wed, 12 Aug 1992 14:53:32 GMT
  9. Lines: 37
  10.  
  11. Hi -
  12.  
  13. We've been experiencing a very strange, yet serious problem...
  14.  
  15. First the details --  MSC 6.0, WINSDK 3.1, protected mode (rc -t)
  16.  
  17. We have an application which makes use of at least 4 user-written
  18. DLLs. Under certain circumstances, when certain functions in the
  19. DLLs are called, some of the variables in the application's data
  20. segment get trashed. This doesn't cause a protection error (immediately)
  21. because it is inside the app's DS. (If it happens to be a pointer
  22. that gets trashed, I get a GPF the next time I access it...)
  23.  
  24. As I rearrange code in the offending DLL(s), different variables in
  25. the app's DS appear to get corrupted.  When I do a memory dump around
  26. the corrupted variable, everything else but the one location seems to
  27. be OK.
  28.  
  29. Some of the DLLs make use of their own DS for static data inside of
  30. them, but none of them have a stack segment. (I say that, but we haven't
  31. done anything to explicitly say no SS, we just don't give a stack size
  32. in the module defintion file).  Also, some of the DLLs have (at times)
  33. been compiled in different memory models than the app, but all passed 
  34. pointers are explicitly declared as FAR.
  35.  
  36. When I trace though with CV, setting a watch on the variable that's
  37. getting trashed, it always gets trashed when I step over a Windows
  38. call, eg MessageBox or SetWindowPos...
  39.  
  40. I know this is a little vague, but it would take a long explanation
  41. to describe everything exactly...  If someone out there has seen this
  42. before and/or needs more detail, I would be happy to provide it...
  43.  
  44. -- 
  45. Scott Harper                       Optical Data Systems, Inc.
  46. scott@ods.com                      1101 E. Arapaho Road
  47. (214) 234-6400                     Richardson, TX  75081
  48.