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

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

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.

I have the same problem on 7.0.4 php v5.2.1

removing php5-curl solves the problem

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
...

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

For more information see:
http://bugs.php.net/bug.php?id=40926
and
http://bugs.debian.org/411982

Confirmed since there is a confirmed bug in debian about this

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

Thanks
chuck

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 :)

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

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

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";

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.

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.

Patch for postgresql-8.3 attached.

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

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

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

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

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/).

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

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!

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...