home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / hp / 12563 < prev    next >
Encoding:
Text File  |  1992-11-04  |  2.1 KB  |  54 lines

  1. Newsgroups: comp.sys.hp
  2. Path: sparky!uunet!munnari.oz.au!yarrina.connect.com.au!codex!bpja
  3. From: bpja@codex.com.au (Brett Adam)
  4. Subject: Is it safe to free() mem alloc'd by xdr routines?
  5. Message-ID: <1992Nov5.081038.1639@codex.oz.au>
  6. Keywords: free, malloc, xdr, rpc
  7. Sender: bpja@codex.oz.au
  8. Reply-To: bpja@codex.com.au
  9. Organization: Codex Software Development Pty Ltd
  10. Date: Thu, 5 Nov 92 08:10:38 GMT
  11. Lines: 41
  12.  
  13.  
  14. I'm experiencing weird memory problems in a system I'm currently porting to the  
  15. HP 700 series.
  16.  
  17. Normally, I'd be looking for bugs in my code, and wouldn't bother the Net  
  18. community, but this software has already been successfully ported to 4 other  
  19. platforms and is running at numerous sites ...
  20.  
  21. What I'm getting are frequent and repeatable crashes in _fcntl() and free().  
  22. Looking at the call chain with xdb indicates that in both cases, the crash is  
  23. the result of a call to either free() or realloc().
  24.  
  25. Looking further, what is actually happening is that an earlier call to free()  
  26. is trashing neighboring memory, such that nearby pointers in a struct are being  
  27. garbled. Hence, when the code gets to free'ing these other pointers, free()  
  28. goes awol.
  29.  
  30. In examining the code, the only 'common factor' I can identify is that the  
  31. memory involved was originally alloc'd by the XDR routines - the memory is the  
  32. result structs of RPC calls.
  33.  
  34. Now under SunOS, and others, it's OK to free() memory returned by the XDR  
  35. routines. However, this may not be the case under HP/UX. 
  36.  
  37. Does anyone know for sure?
  38.  
  39. Are there any other malloc() related issues I should be aware of under HP/UX?
  40.  
  41. (Like, when I did the RS/6000 port, the vendor supplied malloc was outright  
  42. buggy. Some kind soul on the Net finally pointed this out which saved me hours  
  43. of hair pulling. [the workarounds were NON obvious!])
  44.  
  45. Thanks in advance,
  46.  
  47.  
  48.  
  49. -- 
  50. -------------------------------------------------------------------
  51. Brett Adam                                      
  52. Xedoc Software Development Pty. Ltd.           Melbourne, Australia
  53. Phone    :                                           +61 3 696 2490
  54.