Thread

1. exit() calls in libraries

   Peter Eisentraut <peter_e@gmx.net> — 2011-12-05T17:27:41Z

   Debian's package policy and quality check tool lintian reports the
   following (among other things) on the postgresql-9.1 (and earlier)
   packages:
   
   X: libpq5: shlib-calls-exit usr/lib/libpq.so.5.4
   X: libecpg6: shlib-calls-exit usr/lib/libecpg.so.6.3
   
   which is explained as
   
   I: shlib-calls-exit
   N:
   N:   The listed shared library calls the C library exit() or _exit()
   N:   functions.
   N:   
   N:   In the case of an error, the library should instead return an
   N:   appropriate error code to the calling program which can then determine
   N:   how to handle the error, including performing any required clean-up.
   [snip]
   
   The report on libecpg is actually a false positive, because the exit()
   call comes from get_progname() in path.c, which is not called from
   functions in libecpg.
   
   The cases in libpq are
   
         * various places in fe-print.c calling exit(1) when malloc fails,
           presumably having run out of memory, and
         * in libpq-int.h the macro PGTHREAD_ERROR, which is called in
           several places in fe-connect.c and fe-secure.c.
   
   Are these appropriate behaviors?  The fe-print.c stuff probably isn't
   used much anymore.  But the threading stuff is, and it encroaches on the
   exit status space of the libpq-using program.  And does it even make
   sense to call exit() if the thread locking is busted?  Maybe abort()
   would work better?
   
   
   
   

2. Re: exit() calls in libraries

   Alvaro Herrera <alvherre@commandprompt.com> — 2011-12-05T18:04:15Z

   Excerpts from Peter Eisentraut's message of lun dic 05 14:27:41 -0300 2011:
   
   > The cases in libpq are
   > 
   >       * various places in fe-print.c calling exit(1) when malloc fails,
   >         presumably having run out of memory, and
   >       * in libpq-int.h the macro PGTHREAD_ERROR, which is called in
   >         several places in fe-connect.c and fe-secure.c.
   > 
   > Are these appropriate behaviors?  The fe-print.c stuff probably isn't
   > used much anymore.  But the threading stuff is, and it encroaches on the
   > exit status space of the libpq-using program.  And does it even make
   > sense to call exit() if the thread locking is busted?  Maybe abort()
   > would work better?
   
   Having had to battle some exit() calls in the PHP interpreter back when
   I was working in PL/php, I agree that they shouldn't be there -- abort()
   seems more appropriate if the system is truly busted.  As for the
   fr-print.c code, I'm not really sure why don't we just remove it.
   
   -- 
   Álvaro Herrera <alvherre@commandprompt.com>
   The PostgreSQL Company - Command Prompt, Inc.
   PostgreSQL Replication, Consulting, Custom Development, 24x7 support
   
   

3. Re: exit() calls in libraries

   Peter Eisentraut <peter_e@gmx.net> — 2012-01-15T12:53:32Z

   On mån, 2011-12-05 at 15:04 -0300, Alvaro Herrera wrote:
   > Having had to battle some exit() calls in the PHP interpreter back
   > when
   > I was working in PL/php, I agree that they shouldn't be there --
   > abort()
   > seems more appropriate if the system is truly busted.  As for the
   > fr-print.c code, I'm not really sure why don't we just remove it.
   > 
   This is the patch that would get rid of all exit() calls in the
   libraries.