In a signal handler calling functions that might internally try to lock 
a global resource might results in dead-lock.

Example scenario: 
  1. One buggy module mistakenly overwrites a part of heap area with own data.
  2. Another module calls malloc() through System Abstraction Layer to get 
     an allocated memory from the heap area.
  3. malloc() internally locks a resource before manipulating the area.
  4. A segment violation, SIGSEGV, occurs due to accessing to the polluted area.
  5. In a signal handler, some potentially danger functions are used to create 
     a crash dump.
  6. For instance, the first use of fprintf() triggers to get a buffer by 
     calling __flsbuf() normally declared in /usr/include/stdio.h .
  7. __flsbuf() internally calls malloc().
  8. malloc() internally tries to lock a resource, but the resource has been 
     already locked by itself before. 

  Consequently, the signal handler falls into dead-lock. 
  No error report regarding the buggy module would be submitted.


When using fopen() or fdopen(), setbuf() could be called to specify an own buffer.
e.g.

 (current)
   FILE *fp = fopen( filename, "r" );
      sal_uInt8		buffer[4096];
      nBytesRead = fread( buffer, 1, sizeof(buffer), fp );

 (proposal)
   char _buffer[BUFSIZ];
   FILE *fp = fopen( filename, "r" );
   setbuf(fp, _buffer);
      sal_uInt8		buffer[4096];
      nBytesRead = fread( buffer, 1, sizeof(buffer), fp );


When using rtl_uString or rtl_String, be careful to use them, 
e.g.

 (current)
   rtl_uString *ustrCommandArg = NULL;
   osl_getCommandArg( argi, &ustrCommandArg );

 (proposal)
   ... I have no practical idea at this moment ...


References:
  Descriptions regarding a term Async-Signal-Safe could be one of the helpful 
  start points.
  http://docs.sun.com/app/docs/doc/816-5175/attributes-5?a=view