🚀 go-pugleaf

In article <1992Nov17.190901.16350@panix.com>, os2man@panix.com (Larry Salomon Jr.) writes:
|> For some reason, a call to sprintf() instead one of my routines
|> (called getTempName()) hangs my PM application (using C-Set/2 from
|> CD ROM to compile).
|> 
|> Since sprintf() calls malloc() I decided to allocate 100 bytes before
|> calling sprintf() (and immediately free the 100 bytes), and - sure enough -
|> the app hung on the malloc() call.
|> 
|> It sounds like something is getting trashed somewhere, but I don't make
|> any calls to malloc() (I use my own home-grown routines, which I am 99%
|> sure are correct) so it's not like the run-time is suffering from memory
|> fragmentation.
|> 
|> If *anyone* has any ideas what's going on, *please* let me know, since this
|> is a "show stopper."
|> 

We had a situation like this that was caused because someone was using
an uninitialized semaphore handle (value of 0) and requesting that 
semaphore.  Turns out that 0 is indeed a valid handle and is, in fact,
the sem that the C runtime library uses!  Finding this was *not*
easy (a lot of digging with the kernel debugger).  Good Luck!

Oh, yeah, this is only true if you are using the multi-threaded
C library (the sem is used to sync access to global structures for
each calling thread).

I think this is a major bad architectural choice to allow 0 as a
legal semaphore handle, and then to find that it will be used by
something as pervasive as the C runtime library.
+------------------------------------------------------------------------+

   Paul Stevens                        {apple|decwrl}!metaphor!pstevens
   Metaphor Computer Systems           pstevens@metaphor.com
   Mountain View, CA