Thread: exit() calls in libraries

exit() calls in libraries

From
Peter Eisentraut
Date:
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?




Re: exit() calls in libraries

From
Alvaro Herrera
Date:
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


Re: exit() calls in libraries

From
Peter Eisentraut
Date:
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.

Attachment