php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22437 Segmentation violation
Submitted: 2003-02-26 08:29 UTC Modified: 2003-03-10 10:36 UTC
From: olle at compound dot se Assigned: kalowsky (profile)
Status: Closed Package: ODBC related
PHP Version: 4.3.1 OS: Redhat7.2/kernel 2.4.9
Private report: No CVE-ID: None
 [2003-02-26 08:29 UTC] olle at compound dot se
We are running a commercial flight-booking website based upon Apache 1.3.27 and php 4.3.1, querying a PostgresQL 7.1.3 database via ODBC (UnixODBC). The php-interpeter is run as a Apache-module.

Occasionally (30 times a day?) a httpd server process dies caused by segmentation violation. We have collected and looked at 30 dumped cores and the calling stack appear to be somewhat different each time. Our conclusion is that the segmentation violations are probably not a result of the functions appearing on the stack of the dumped cores, but more likely caused by corrupted datastructures which may have been around for some time.

In an attempt to isolate the cause of our problems we ran a single httpd server in control of valgrind (an I386 emulator/memory allocation analyser in software). Valgrind indicates that the PHP 4.3.1 ODBC-functions repeatedly write and read from invalid memory adresses. Typically 4 bytes beyond a malloced block of memory. We believe these writes (or reads?) may be the cause of our crashing httpd processes.

Below is a quote of the Valgrind output. Furter down you will fins our PHP configuration.

==29000== Invalid write of size 4
==29000==    at 0x4664821F: CLConnect (SQLConnect.c:258)
==29000==    by 0x43D11110: ??? (SQLConnect.c:1852)
==29000==    by 0x43D13555: SQLConnect (SQLConnect.c:3483)
==29000==    by 0x44B4DE09: odbc_sqlconnect (/opt/tools/php/php-4.3.1/ext/odbc/php_odbc.c:2136)
==29000==    Address 0x40FC254C is 4 bytes after a block of size 4 alloc'd
==29000==    at 0x400483E4: malloc (vg_clientfuncs.c:100)
==29000==    by 0x466481EB: CLConnect (SQLConnect.c:241)
==29000==    by 0x43D11110: ??? (SQLConnect.c:1852)
==29000==    by 0x43D13555: SQLConnect (SQLConnect.c:3483)
==29000==
==29000== Invalid write of size 4
==29000==    at 0x46648393: CLConnect (SQLConnect.c:341)
==29000==    by 0x43D11110: ??? (SQLConnect.c:1852)
==29000==    by 0x43D13555: SQLConnect (SQLConnect.c:3483)
==29000==    by 0x44B4DE09: odbc_sqlconnect (/opt/tools/php/php-4.3.1/ext/odbc/php_odbc.c:2136)
==29000==    Address 0x40FC2548 is 0 bytes after a block of size 4 alloc'd
==29000==    at 0x400483E4: malloc (vg_clientfuncs.c:100)
==29000==    by 0x466481EB: CLConnect (SQLConnect.c:241)
==29000==    by 0x43D11110: ??? (SQLConnect.c:1852)
==29000==    by 0x43D13555: SQLConnect (SQLConnect.c:3483)
==29000==
==29000== Invalid read of size 4
==29000==    at 0x466483B7: CLConnect (SQLConnect.c:350)
==29000==    by 0x43D11110: ??? (SQLConnect.c:1852)
==29000==    by 0x43D13555: SQLConnect (SQLConnect.c:3483)
==29000==    by 0x44B4DE09: odbc_sqlconnect (/opt/tools/php/php-4.3.1/ext/odbc/php_odbc.c:2136)
==29000==    Address 0x40FC2548 is 0 bytes after a block of size 4 alloc'd
==29000==    at 0x400483E4: malloc (vg_clientfuncs.c:100)
==29000==    by 0x466481EB: CLConnect (SQLConnect.c:241)
==29000==    by 0x43D11110: ??? (SQLConnect.c:1852)
==29000==    by 0x43D13555: SQLConnect (SQLConnect.c:3483)
==29000==
==29000== Invalid write of size 2
==29000==    at 0x4676214C: SQLGetInfo (info.c:671)
==29000==    by 0x466483BF: CLConnect (SQLConnect.c:360)
==29000==    by 0x43D11110: ??? (SQLConnect.c:1852)
==29000==    by 0x43D13555: SQLConnect (SQLConnect.c:3483)
==29000==    Address 0x40FC2554 is 12 bytes after a block of size 4 alloc'd
==29000==    at 0x400483E4: malloc (vg_clientfuncs.c:100)
==29000==    by 0x466481EB: CLConnect (SQLConnect.c:241)
==29000==    by 0x43D11110: ??? (SQLConnect.c:1852)
==29000==    by 0x43D13555: SQLConnect (SQLConnect.c:3483)

#! /bin/sh
#
# Created by configure

'./configure' \
'--enable-shared' \
'--with-apxs' \
'--with-unixODBC' \
'--with-xml' \
'--enable-xslt' \
'--with-xslt-sablot=/usr/local' \
'--enable-sablot-errors-descriptive' \
'--with-dom=/usr/local' \
'--with-zlib' \
'--enable-trans-sid' \
'--with-iconv=/usr/local' \
'--with-imap' \
'--with-gettext' \
'--with-tsrm-pthreads' \
'--enable-roxen-zts' \
'--with-mysql' \
'-with-kerberos=/usr/kerberos' \
"$@"

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-26 09:42 UTC] kalowsky@php.net
sounds like a problem on my end... icky...
 [2003-02-26 09:44 UTC] olle at compound dot se
I have run the Valgrind test with PHP 4.2.3 instead of 4.3.1. The 4.2.3 test produced none of the "Invalid write" messages that 4.3.1 produced. PHP 4.2.3 was built with an identical config-file as 4.3.1.
Unfortunately I believe we upgraded from 4.2.3 to get rid of ODBC-problems...
 [2003-02-26 09:48 UTC] sniper@php.net
don't change the status..

 [2003-02-26 09:59 UTC] mboeren@php.net
From php_odbc.c:
void odbc_do_connect(INTERNAL_FUNCTION_PARAMETERS, int persistent) 

...
len = strlen(db) + strlen(uid) + strlen(pwd) + sizeof(ODBC_TYPE) + 5;
hashed_details = emalloc(len);
hashed_len = sprintf(hashed_details, "%s_%s_%s_%s_%d", ODBC_TYPE, db, uid, pwd, cur_opt);

==> shouldn't len include the length of the string representation of cur_opt?

Hope this helps, Marc.


 [2003-02-26 15:32 UTC] iliaa@php.net
Try applying the patch at (againt latest stable CVS):
http://bb.prohost.org/odbc43.txt

If the problem is the result of sprintf() overflow this should correct it.
 [2003-03-10 01:54 UTC] olle at compound dot se
Thank you for your prompt answers.
I have patched the original 4.3.1 php_odbc.c as suggested in the "[26 Feb 9:59am CST] mboeren@php.net"-note, and the Valgrind "invalid write"-messages did go away. We also found memory misuse in the UnixODBC code, which we have corrected. 
Things are running better, but we are still experiencing segmentation violations which we think originate from the Sablot XML-package.
 [2003-03-10 10:36 UTC] sniper@php.net
But this odbc related bug is now fixed -> closed.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 14:01:28 2024 UTC