PHP (cli) exits with a segfault if pg_connect() called.

Bug #63141 reported by fletch
122
This bug affects 2 people
Affects Status Importance Assigned to Milestone
php5 (Ubuntu)
Low
Unassigned
Hardy
Undecided
Unassigned
postgresql-8.3 (Debian)
Fix Released
Unknown
postgresql-8.3 (Ubuntu)
Undecided
Unassigned
Hardy
Medium
Martin Pitt

Bug Description

SRU TEST CASE:
 * sudo apt-get install postgresql-8.3 php-cli php-curl php-pgsql
 * php -r 'pg_connect("host=localhost");'
   warning: pg_connect(): Unable to connect to PostgreSQL server: fe_sendauth: no password supplied in Command line code on line 1
   Segmentation fault (core dumped)

--- Original bug report -------------------------------------

Binary package hint: php5-cli

test.php:
<?php pg_connect("dbname=validorinvalidname user=validorinvaliduser pass=validorinvalidpass"); print "connected (or not)\n"; ?>

output of php test.php:
connected (or not)
SegmetationFault

In short, calling pg_connect() is causing a Segmentation Fault **after** the successful completion of the script. Explicitly calling pg_close() before the script ends has no effect. The function does not need to successfully connect to a db to cause the error. I cannot find a combination of different connection string paramaters that make any difference to the bug.

PHP packages installed

libapache2-mod-php5 5.1.2-1ubuntu3.2
php5-cli 5.1.2-1ubuntu3.2
php5-cgi 5.1.2-1ubuntu3.2
php5-common 5.1.2-1ubuntu3.2
php5-pgsql 5.1.2-1ubuntu3.2
php5-curl 5.1.2-1ubuntu3.2
php5-gd 5.1.2-1ubuntu3.2
php5-imap 5.1.2-1ubuntu3.2
php5-mysql 5.1.2-1ubuntu3.2
php5-mysqli 5.1.2-1ubuntu3.2
php5-xsl 5.1.2-1ubuntu3.2

PostgreSQL packages installed:

postgresql-8.1 8.1.4-0ubuntu1
postgresql-contrib-8.1 8.1.4-0ubuntu1
postgresql-comon1 53ubuntu3
postgresql-client-8.1 8.1.4-0ubuntu1
postgresql-client-common 53ubuntu3

WORKAROUNDS:

1) Removing php5-curl solves the problem

2) Moving the line "extension=curl.so" into pgsql.ini (before or after "extension=pgsql.so", it doesn't matter) solves the problem too, and curl can still be used.

Revision history for this message
Ralph Janke (txwikinger) wrote :

Thanks for submitting the bug report.

I tested this with php5 5.1.2-1ubuntu3.2 on dapper and could not reproduce this.

Is this problem still current or fixed by the updates ?

Thanks

Changed in php5:
assignee: nobody → rjanke
status: Unconfirmed → Needs Info
Revision history for this message
fletch (richard-artumi) wrote :

Using php5 5.1.6-1ubuntu2.3 on dapper I can no longer see this bug as described. I am still getting a seg fault on my scripts after they have completed, but this bug is not the cause, as the test case no longer works for me either.

Revision history for this message
al_n (alon-f4w) wrote :

I have the same problem on 7.0.4 php v5.2.1

Revision history for this message
al_n (alon-f4w) wrote :

removing php5-curl solves the problem

Revision history for this message
milankowww (milan-pikula) wrote :
Download full text (24.4 KiB)

I have the bug on php 5.2.1-0ubuntu1.1, libpq5 8.2.4-0ubuntu0.7.04, i386 architecture.

Thanks for the curl hint. Moving the line "extension=curl.so" into pgsql.ini (before or after "extension=pgsql.so", it doesn't matter) solves the problem too, and I can still use curl. According to mine 3 minutes of playing it is a bug of postgresql, and curl just happens to move the stuff around in the memory so that it shows.

What I did is that I started PHP through dmalloc library. First, I got this bug in SNMP:

root@webway:/etc/php5/cli/conf.d# LD_PRELOAD=/usr/lib/libdmalloc.so.4 php /tmp/pg.php
*** glibc detected *** php: free(): invalid pointer: 0xb6cfe180 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb799b7cd]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb799ee30]
/usr/lib/libnetsnmp.so.9(read_config_files+0x456)[0xb6efcf36]
/usr/lib/libnetsnmp.so.9(read_premib_configs+0x163)[0xb6efd283]
/usr/lib/libnetsnmp.so.9(init_snmp+0x324)[0xb6ee1fc4]
/usr/lib/php5/20060613+lfs/snmp.so(zm_startup_snmp+0x24)[0xb709de64]
php(zend_startup_module_ex+0xe0)[0x82bf720]
php(zend_hash_apply+0x4c)[0x82c33bc]
php(zend_startup_modules+0x51)[0x82bdc01]
php(php_module_startup+0x6c8)[0x8272068]
php(main+0x280)[0x8348350]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7949ebc]
php[0x8096191]
======= Memory map: ========
08048000-0854e000 r-xp 00000000 09:00 637820 /usr/bin/php5
0854e000-08583000 rw-p 00505000 09:00 637820 /usr/bin/php5
08583000-085a9000 rw-p 08583000 00:00 0 [heap]
b6c79000-b6c84000 r-xp 00000000 09:00 669427 /lib/libgcc_s.so.1
b6c84000-b6c85000 rw-p 0000a000 09:00 669427 /lib/libgcc_s.so.1
b6c8f000-b6ddb000 rwxp b6c8f000 00:00 0
b6ddb000-b6de4000 r-xp 00000000 09:00 686412 /lib/tls/i686/cmov/libnss_files-2.5.so
b6de4000-b6de6000 rw-p 00008000 09:00 686412 /lib/tls/i686/cmov/libnss_files-2.5.so
b6de6000-b6e01000 rwxp b6de6000 00:00 0
b6e01000-b6e04000 r-xp 00000000 09:00 638515 /usr/lib/libgpg-error.so.0.3.0
b6e04000-b6e05000 rw-p 00002000 09:00 638515 /usr/lib/libgpg-error.so.0.3.0
b6e05000-b6e54000 r-xp 00000000 09:00 638462 /usr/lib/libgcrypt.so.11.2.2
b6e54000-b6e56000 rw-p 0004e000 09:00 638462 /usr/lib/libgcrypt.so.11.2.2
b6e56000-b6e89000 r-xp 00000000 09:00 638730 /usr/lib/libxslt.so.1.1.20
b6e89000-b6e8a000 rw-p 00032000 09:00 638730 /usr/lib/libxslt.so.1.1.20
b6e8a000-b6e9a000 r-xp 00000000 09:00 638441 /usr/lib/libexslt.so.0.8.13
b6e9a000-b6e9b000 rw-p 0000f000 09:00 638441 /usr/lib/libexslt.so.0.8.13
b6e9b000-b6ea5000 rwxp b6e9b000 00:00 0
b6ea5000-b6eac000 r-xp 00000000 09:00 669469 /lib/libwrap.so.0.7.6
b6eac000-b6ead000 rw-p 00007000 09:00 669469 /lib/libwrap.so.0.7.6
b6ead000-b6f34000 r-xp 00000000 09:00 638615 /usr/lib/libnetsnmp.so.9.0.1
b6f34000-b6f37000 rw-p 00086000 09:00 638615 /usr/lib/libnetsnmp.so.9.0.1
b6f37000-b6f55000 rw-p b6f37000 00:00 0
b6f55000-b6f58000 rwxp b6f55000 00:00 0
b6f58000-b6f5e000 r-xp 00000000 09:00 753044 /usr/lib/php5/20060613+lfs/xsl.so
b6f5e000-b6f5f000 rw-p 00005000 09:00 753044 /usr/lib/php5/20060613+lfs/xsl.so
b6f5f000-b706b000 r-xp 00000000 09:00 638662 /usr/lib/librecode.so.0.0.0
...

Revision history for this message
Ondřej Surý (ondrej) wrote :

There is a workaround. If it segfaults, then load modules in reverse order manually from php.ini.

Revision history for this message
Ondřej Surý (ondrej) wrote :
Revision history for this message
Ralph Janke (txwikinger) wrote :

Confirmed since there is a confirmed bug in debian about this

Changed in php5:
assignee: txwikinger → nobody
status: Needs Info → Confirmed
Changed in php5:
status: Unknown → Confirmed
Ralph Janke (txwikinger)
Changed in php5:
importance: Undecided → Low
description: updated
Revision history for this message
Chuck Short (zulcss) wrote :

If possible can you test this with hardy from a live cd?

Thanks
chuck

Revision history for this message
fletch (richard-artumi) wrote :

I wont be able to for a couple of weeks. After that I will test this, if it has not been done before. If I remember :)

Revision history for this message
Russell Smith (mr-russ) wrote :

I've run the test in the original test script with slight different connect parameters on hardy up to date today. I didn't get a crash;

## My php5 conf.d looks like this to load curl.ini and pgsql.ini
mr-russ@bob:~$ ls -l /etc/php5/cli/conf.d/
total 16
-rw-r--r-- 1 root root 54 2008-02-28 07:52 curl.ini
-rw-r--r-- 1 root root 52 2008-02-28 07:52 pdo.ini
-rw-r--r-- 1 root root 65 2008-02-28 07:52 pdo_pgsql.ini
-rw-r--r-- 1 root root 61 2008-02-28 07:52 pgsql.ini

mr-russ@bob:~$ aptitude search php5 | grep '^i'
i libapache2-mod-php5 - server-side, HTML-embedded scripting langu
i A php5 - server-side, HTML-embedded scripting langu
i php5-cli - command-line interpreter for the php5 scri
i A php5-common - Common files for packages built from the p
i php5-curl - CURL module for php5
i php5-pgsql - PostgreSQL module for php5
mr-russ@bob:~$ aptitude search postgresql | grep '^i'
i postgresql - object-relational SQL database (latest ver
i postgresql-8.3 - object-relational SQL database, version 8.
i postgresql-client - front-end programs for PostgreSQL (latest
i postgresql-client-8.3 - front-end programs for PostgreSQL 8.3
i postgresql-client-common - manager for multiple PostgreSQL client ver
i postgresql-common - PostgreSQL database-cluster manager
i postgresql-contrib - additional facilities for PostgreSQL (late
i postgresql-contrib-8.3 - additional facilities for PostgreSQL
i postgresql-doc - documentation for the PostgreSQL database
i postgresql-doc-8.3 - documentation for the PostgreSQL database

Revision history for this message
Russell Smith (mr-russ) wrote :

Hi,

After a bit of debugging, some pushing and a big wait, there is a proposed patch for this. Really this is a bug in PostgreSQL as listed in the PHP bug report.

I'm not sure if this should be moved. So I'm leaving it here. But it is certainly a bug in PostgreSQL.

Bug thread reported by me: http://archives.postgresql.org/pgsql-bugs/2008-09/msg00001.php
Proposed Patch for PostgreSQL: http://archives.postgresql.org/pgsql-hackers/2008-10/msg01353.php

Revision history for this message
Russell Smith (mr-russ) wrote :

I have marked all the moodle reports as duplicates of this bug. They exhibit the same symptoms as each other.

The workaround for the pg_connect generic bug is to disable the ssl connection. Manually altering the moodle connect string in connection library to disable ssl also removes the segmentation fault in the moodle cron run.

The very simple patch I used to test moodle is at the bottom. This is a workaround for the moodle problem if you don't need to use SSL for your moodle db connections. You could also disable ssl connections at the postgresql end by;

1. ssl = false in postgresql.conf
2. alter pg_hba.conf to only have a hostnossl entry for the moodle user.

2 is a better option as it doesn't disable all instances of ssl on the server. It also will be faster for moodle as negotiating SSL is slow.

Overall the underlying problem is exactly the same, hence they are all duplicates.

--- adodb-postgres64.inc.php.orig 2008-11-04 20:26:31.000000000 +1100
+++ adodb-postgres64.inc.php 2008-11-04 20:19:02.000000000 +1100
@@ -668,6 +668,7 @@
        if ($user) $str .= " user=".$user;
        if ($pwd) $str .= " password=".$pwd;
     if ($db) $str .= " dbname=".$db;
+ $str .= " sslmode=disable";
   }

   //if ($user) $linea = "user=$user host=$linea password=$pwd dbname=$db port=5432";

Russell Smith (mr-russ)
Changed in postgresql-8.3:
status: New → Confirmed
Revision history for this message
Russell Smith (mr-russ) wrote :

Hi,

I've taken the latest version of the PG patch and backported it to 8.3.3 as released in hardy.

Before the application of the below patch, the segfault appears on the following code;

<?php
$conn = pg_connect('host=localhost dbname=postgres sslmode=require');
?>

After the patch application. No segfault is experienced.

That said, I'm not experienced enough with SSL to be sure I've back ported the patch properly.

Emmet Hikory (persia)
Changed in php5:
status: Confirmed → Triaged
Changed in postgresql-8.3:
status: Confirmed → Triaged
Revision history for this message
leopard (leopard-not-a) wrote :

Ubuntu 8.04
Sometimes I have error in log. High loaded server, online system writen by PHP and using Postgresql.
$ tail -f /var/log/messages
Apr 9 13:15:01 dbserver kernel: [ 7110.775499] php[14257]: segfault at 00000000 eip b6e98e8f esp bfef4ca0 error 4
Apr 9 13:15:01 dbserver kernel: [ 7110.775786] php[14266]: segfault at 00726f72 eip 00726f72 esp bfc6ca1c error 14
Apr 9 13:25:56 dbserver php: PHP Warning: pg_query(): Query failed: server closed the connection unexpectedly ^IThis probably means the server terminated abnormally ^Ibefore or while processing the request. in /var/www/tut1/simplescripts/start.php on line 43
Apr 9 13:38:27 dbserver -- MARK --
Apr 9 13:58:27 dbserver -- MARK --
Apr 9 14:13:08 dbserver kernel: [10591.395416] php[3724]: segfault at 00000172 eip 00000172 esp bfe1c46c error 14
Apr 9 14:38:27 dbserver -- MARK --
Apr 9 14:58:27 dbserver -- MARK --
Apr 9 15:10:01 dbserver kernel: [13996.938272] php[32104]: segfault at 00000000 eip b6efde8f esp bff324e0 error 4
Apr 9 15:10:01 dbserver kernel: [13996.938946] php[32107]: segfault at 00000000 eip 00000000 esp bfbc616c error 14
Apr 9 15:17:46 dbserver kernel: [14461.355480] php[3746]: segfault at 00000000 eip b6ee5e8f esp bfe16bb0 error 4
Apr 9 15:38:27 dbserver -- MARK --
Apr 9 15:58:27 dbserver -- MARK --

$ uname -a
Linux dbserver 2.6.24-23-server #1 SMP Wed Apr 1 22:22:14 UTC 2009 i686 GNU/Linux

$ php -v
PHP 5.2.9-0.dotdeb.1 with Suhosin-Patch 0.9.7 (cli) (built: Mar 8 2009 23:41:21)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with XCache v1.2.2, Copyright (c) 2005-2007, by mOo

All errors come from PHP (cli), which server run in cron
I have email from cron, for example

Cron /usr/bin/php /*****.php
Segmentation fault

I try change PHP (as you see by version, before 5.2.6, 5.2.8), update postgresql (now version PostgreSQL 8.3.7). Web server nginx (nginx version: nginx/0.6.32) and php run by fastcgi using spawn-fcgi from lighttpd.

I attached list of installed packages

P.S. Sorry for my bad English.

Revision history for this message
Ondřej Surý (ondrej) wrote :

Patch for postgresql-8.3 attached.

affects: php5 (Debian) → postgresql-8.3 (Debian)
Ondřej Surý (ondrej)
Changed in postgresql-8.3 (Ubuntu):
status: Triaged → Confirmed
Revision history for this message
Russell Smith (mr-russ) wrote :

I attached basically the same patch over 12 months ago. What can be done to actually get this patch applied and released?

Revision history for this message
Ondřej Surý (ondrej) wrote :

Hi Russell, I have noticed your patch only after I did manually apply 8.4 patch to postgresql-8.3 for Debian bug.

Martin, could you please comment either here or in debian bug, since you're maintainer of both Ubuntu and Debian packages?

Ondrej

Revision history for this message
Martin Pitt (pitti) wrote :

Wontfix for lucid, since it's obsoleted by 8.4. Should be fixed for hardy, though, as LTS.

Changed in postgresql-8.3 (Ubuntu):
status: Confirmed → Won't Fix
Changed in postgresql-8.3 (Ubuntu Hardy):
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Martin Pitt (pitti)
status: Triaged → In Progress
Changed in php5 (Ubuntu Hardy):
status: New → Invalid
Changed in php5 (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Martin Pitt (pitti) wrote :

Current patch wasn't approved/backported by upstream yet, and the backport proposed in the Debian bug doesn't build.

Changed in postgresql-8.3 (Ubuntu Hardy):
status: In Progress → Triaged
Revision history for this message
Ondřej Surý (ondrej) wrote :

I have updated the debbug411982.patch to compile cleanly after evaluating commited postgresql-8.4 code and consequences of pq_lockarray not freed (previous patch had a typo s/pqlockarray/pq_lockarray/).

Martin Pitt (pitti)
Changed in postgresql-8.3 (Ubuntu Hardy):
status: Triaged → In Progress
Martin Pitt (pitti)
description: updated
description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

Uploaded to hardy-proposed, waiting for other SRU team member to ack/accept.

Revision history for this message
Colin Watson (cjwatson) wrote : Please test proposed package

Accepted postgresql-8.3 into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in postgresql-8.3 (Ubuntu Hardy):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.4 KiB)

This bug was fixed in the package postgresql-8.3 - 8.3.10-0ubuntu8.04

---------------
postgresql-8.3 (8.3.10-0ubuntu8.04) hardy-proposed; urgency=low

  * New upstream bug fix release: (LP: #557408)
    - Add new configuration parameter ssl_renegotiation_limit to control
      how often we do session key renegotiation for an SSL connection.
      This can be set to zero to disable renegotiation completely, which
      may be required if a broken SSL library is used. In particular,
      some vendors are shipping stopgap patches for CVE-2009-3555 that
      cause renegotiation attempts to fail.
    - Fix possible deadlock during backend startup.
    - Fix possible crashes due to not handling errors during relcache
      reload cleanly.
    - Fix possible crash due to use of dangling pointer to a cached plan.
    - Fix possible crashes when trying to recover from a failure in
      subtransaction start.
    - Fix server memory leak associated with use of savepoints and a
      client encoding different from server's encoding.
    - Fix incorrect WAL data emitted during end-of-recovery cleanup of a
      GIST index page split.
      This would result in index corruption, or even more likely an error
      during WAL replay, if we were unlucky enough to crash during
      end-of-recovery cleanup after having completed an incomplete GIST
      insertion.
    - Make substring() for bit types treat any negative length as meaning
      "all the rest of the string".
      The previous coding treated only -1 that way, and would produce an
      invalid result value for other negative values, possibly leading to
      a crash (CVE-2010-0442). (Closes: #567058)
    - Fix integer-to-bit-string conversions to handle the first
      fractional byte correctly when the output bit width is wider than
      the given integer by something other than a multiple of 8 bits.
    - Fix some cases of pathologically slow regular expression matching.
    - Fix assorted crashes in xml processing caused by sloppy memory
      management.
      This is a back-patch of changes first applied in 8.4. The 8.3 code
      was known buggy, but the new code was sufficiently different to not
      want to back-patch it until it had gotten some field testing.
    - Fix bug with trying to update a field of an element of a
      composite-type array column.
    - Fix the STOP WAL LOCATION entry in backup history files to report
      the next WAL segment's name when the end location is exactly at a
      segment boundary.
    - Fix some more cases of temporary-file leakage.
      This corrects a problem introduced in the previous minor release.
      One case that failed is when a plpgsql function returning set is
      called within another function's exception handler.
    - Improve constraint exclusion processing of boolean-variable cases,
      in particular make it possible to exclude a partition that has a
      "bool_column = false" constraint.
    - When reading "pg_hba.conf" and related files, do not treat
      @something as a file inclusion request if the @ appears inside
      quote marks; also, never treat @ by itself as a file inclusion
      request.
      This prevent...

Read more...

Changed in postgresql-8.3 (Ubuntu Hardy):
status: Fix Committed → Fix Released
Changed in postgresql-8.3 (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.