home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / programm / 5215 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.2 KB  |  48 lines
  1. Newsgroups: comp.unix.programmer
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!noose.ecn.purdue.edu!ecn.purdue.edu!kudva
  3. From: kudva@ecn.purdue.edu (Gautham K. Kudva)
  4. Subject: Signal Handlers and malloc()
  5. Message-ID: <1992Nov9.064910.778@noose.ecn.purdue.edu>
  6. Followup-To: comp.unix.programmer
  7. Sender: news@noose.ecn.purdue.edu (USENET news)
  8. Organization: Purdue University Engineering Computer Network
  9. Date: Mon, 9 Nov 1992 06:49:10 GMT
  10. Lines: 36
  11.  
  12.  
  13. Hi netters,
  14.      I've come across a problem with signal handlers that has me completely
  15. stumped. I'm hoping that someone will be able to help me on this. The
  16. environment I'm using is SunOS 4.1 on a Sparc IPC, but I expect that this
  17. would be a problem on any Unix platform.
  18.  
  19.      I've written a signal handler for the VTALRM signal. The signal
  20. handler calls another routine which does quite a bit of work. This program
  21. start crashing in an unpredictable fashion. On using purify, it gave me the
  22. following error (that software is simply awesome!!):
  23.  
  24. Warning: calling malloc(16) while in a call
  25.  to malloc/free/memalign.  Probably from a signal handler.
  26.  malloc/free/memalign are *not* reentrant and this may
  27.  cause a later segv.
  28.  
  29. I have some malloc calls within the routine called by the signal handler,
  30. and apparently the signal handler was invoked by interrupting a malloc
  31. call.  Did some reading and sure enough, Rich Stevens' excellent book
  32. "Advanced programming in the UNIX environment" warns of exactly this
  33. problem. Now my question is - "Is there a fix?". I could coneivably guard
  34. all my malloc/free calls with sigblocks... but I'm writing something that
  35. will be used by other people. There's no way I can be sure that everyone
  36. else will also guard their malloc/free calls. Besides, there may be other
  37. routines that are non-reentrant in this fashion. I guess what I'm looking
  38. for is a library of reentrant or guarded versions of the standard
  39. non-reentrant calls. With the diverse uses to which signals have been put
  40. over the years, surely something like this exists? Public domain versions
  41. would be great, but commercial ones are ok too.
  42.  
  43. Please post or e-mail. I will summarize.
  44.  
  45. Thanks much in advance,
  46. Gautham Kudva
  47. kudva@ecn.purdue.edu
  48.