PHP :: Bug #19456 :: segfault using ODBC functions

Bug #19456

segfault using ODBC functions

Submitted:

2002-09-17 12:37 UTC

Modified:

2002-10-08 21:53 UTC

Votes:	2
Avg. Score:	5.0 ± 0.0
Reproduced:	2 of 2 (100.0%)
Same Version:	1 (50.0%)
Same OS:	1 (50.0%)

From:

james dot jones at firstinvestors dot com

Assigned:

Status:

No Feedback

Package:

ODBC related

PHP Version:

4.2.3

OS:

Redhat Linux

Private report:

CVE-ID:

None

View Add Comment Developer Edit

Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.

Password:

Status:
Package:
Bug Type:
Summary:
From:	james dot jones at firstinvestors dot com
New email:
PHP Version:		OS:

New Comment:

[2002-09-17 12:37 UTC] james dot jones at firstinvestors dot com

I've been running PHP 4.2.1 for some time on a test machine with the following configure options:

'./configure' \
'--with-apxs' \
'--with-ibm-db2=shared' \
'--with-ldap=shared' \
'--with-mcrypt=shared' \
'--with-mhash=shared' \
'--enable-ftp' \
'--with-config-file-path=/etc' \
'--enable-trans-sid' \
'--enable-debug' \
'--with-png-dir=/usr/local' \
'--with-jpeg-dir=/usr/local' \
'--with-zlib=/usr/local' \
'--with-gd=/usr/local' \

Worked fine under Apache 1.3.20. Then I started doing some upgrades, upgrading Apache to 1.3.26 and OpenSSL to 0.9.6g. At this point, PHP stopped working, generating a segfault (11) in my Apache log every time an ODBC function was called. The following script would exhibit this behavior:

<?php
$dbconn = odbc_connect(<dsn>,<user>,<password>);
?>

I was unable to get PHP to segfault with scripts that did not use ODBC functions.

I then recompiled PHP as a CGI function to get a backtrace, which gives me this:

#0  0x407173ac in ?? ()
#1  0x40117780 in __libc_start_main () from /lib/libc.so.6

I also stepped through the code while running the script given above. PHP appears to complete processing entirely, but segfaults when exiting. The exit_status variable was 0.

I then stepped through the code while running a script with no odbc code:

<?php print("Test!\n"); ?>

This appears to complete exactly the same way the ODBC script did, with an exit_status of 0, but it does not segfault.

Note that I've also upgraded to PHP 4.2.3 and I get the exact same problem. Here is a summary of my relevant versions:

Linux Kernel 2.2.16
Apache 1.3.26
OpenSSL 0.9.6g
mod_ssl 2.8.10-1.3.26
PHP 4.2.3
libc 2.2.3

Please let me know if I can supply any additional information.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports

[2002-09-17 13:26 UTC] james dot jones at firstinvestors dot com

I just recompiled PHP 4.0.6 with all the same options and ODBC works there. So this seems to be unique to 4.2.x.

I noticed that I had an old version of apxs is /usr/sbin/apxs (which shouldn't have mattered since I designated the correct apxs in my configure script). Unfortunately, after changing that I still get the same problem. So that's not it.

[2002-09-17 15:13 UTC] kalowsky@php.net

1) Turn on your SQL Logging feature (it will require editing your odbc.ini).  Add the results of said CONNECT logging to the bug report if you can. 

2) Please post a backtrace of the segfault, it will help.  Honest.  :)

Also moving this over to ODBC

[2002-09-17 15:30 UTC] james dot jones at firstinvestors dot com

Please note that I *did* submit the backtrace. It's very short (only two lines), presumably because the segfault occurs as the program is exiting.

I'll try to get an ODBC trace, but again, note that the problem does NOT occur during the connect, but only as the program exits.

[2002-09-17 17:29 UTC] kalowsky@php.net

While I understand that the connect happens just fine, I'm wondering if some resources are not being cleaned up.  Since this is happening only for you with the ODBC compiled, I have no real way to tell until I see the SQL Log :)

I was hoping there was more to the backtrace that you didn't post :(  That seems rather unusable to me.

[2002-09-18 09:50 UTC] james dot jones at firstinvestors dot com

This morning I built PHP without using shared modules and it works. I've noticed this with other modules, too: sometimes if I just link them statically, they work fine, but if I share them, they don't work.

I was able to generate an ODBC trace (really a CLI trace, to be pedantic) for a non-working CGI version of 4.2.1:

[ Process: 21425, Thread: 1024 ]
[ Date & Time:          09-18-2002 10:26:51.748775 ]
[ Product:              QDB2/LINUX 7.1.0.40 ]
[ Level Identifier:     03010105 ]
[ CLI Driver Version:   07.02.0000 ]
[ Informational Tokens: "DB2 v7.1.0.40","s010415","U475381" ]



[0000021425 0000001024] [1032323211.748941 - 09-18-2002 10:26:51.748941] SQLAllocEnv( phEnv=&08200acc )
[0000021425 0000001024] [1032323211.749050 - 09-18-2002 10:26:51.749050]     ---> Time elapsed - 0 seconds

[0000021425 0000001024] [1032323211.749343 - 09-18-2002 10:26:51.749343] SQLAllocEnv( phEnv=0:1 )
[0000021425 0000001024] [1032323211.749419 - 09-18-2002 10:26:51.749419]     <--- SQL_SUCCESS   Time elapsed - +4.780000E-004 seconds

[0000021425 0000001024] [1032323211.749508 - 09-18-2002 10:26:51.749508] SQLAllocConnect( hEnv=0:1, phDbc=&08200ad0 )
[0000021425 0000001024] [1032323211.749602 - 09-18-2002 10:26:51.749602]     ---> Time elapsed - +8.900000E-005 seconds

[0000021425 0000001024] [1032323211.749798 - 09-18-2002 10:26:51.749798] SQLAllocConnect( phDbc=0:1 )
[0000021425 0000001024] [1032323211.749889 - 09-18-2002 10:26:51.749889]     <--- SQL_SUCCESS   Time elapsed - +3.810000E-004 seconds

[0000021425 0000001024] [1032323211.749973 - 09-18-2002 10:26:51.749973] SQLConnect( hDbc=0:1, szDSN="****", cbDSN=-3, szUID="****", cbUID=-3, szAuthStr="****", cbAuthStr=-3 )
[0000021425 0000001024] [1032323211.750215 - 09-18-2002 10:26:51.750215]     ---> Time elapsed - +8.400000E-005 seconds
    sqlccsend( ulBytes - 1622 )
    sqlccsend( Handle - 1085627784 )
    sqlccsend( ) - rc - 0, time elapsed - +1.550000E-004
    sqlccrecv( )
    sqlccrecv( ulBytes - 1262 ) - rc - 0, time elapsed - +4.329000E-003
    sqlccsend( ulBytes - 611 )
    sqlccsend( Handle - 1085627784 )
    sqlccsend( ) - rc - 0, time elapsed - +7.000000E-005
    sqlccrecv( )
    sqlccrecv( ulBytes - 237 ) - rc - 0, time elapsed - +1.099620E-001
[0000021425 0000001024] [1032323211.868023 - 09-18-2002 10:26:51.868023] ( DBMS NAME="DB2/SUN", Version="07.02.0000", Fixpack="0x23010105" )
[0000021425 0000001024] [1032323211.868184 - 09-18-2002 10:26:51.868184] 
[0000021425 0000001024] [1032323211.868226 - 09-18-2002 10:26:51.868226] ( Application Codepage=819, Database  Codepage=1252, Char Send/Recv Codepage=819, Graphic Send/Recv Codepage=819, iGraphic Codepage=819 )
[0000021425 0000001024] [1032323211.868395 - 09-18-2002 10:26:51.868395] 

[0000021425 0000001024] [1032323211.868475 - 09-18-2002 10:26:51.868475] SQLConnect( )
[0000021425 0000001024] [1032323211.868520 - 09-18-2002 10:26:51.868520]     <--- SQL_SUCCESS   Time elapsed - +1.185470E-001 seconds
[0000021425 0000001024] [1032323211.868576 - 09-18-2002 10:26:51.868576] ( DSN=""****"" )
[0000021425 0000001024] [1032323211.868644 - 09-18-2002 10:26:51.868644] 
[0000021425 0000001024] [1032323211.868685 - 09-18-2002 10:26:51.868685] ( UID=""****"" )
[0000021425 0000001024] [1032323211.868753 - 09-18-2002 10:26:51.868753] 
[0000021425 0000001024] [1032323211.868794 - 09-18-2002 10:26:51.868794] ( PWD="****" )
[0000021425 0000001024] [1032323211.868861 - 09-18-2002 10:26:51.868861] 

[0000021425 0000001024] [1032323211.869275 - 09-18-2002 10:26:51.869275] SQLDisconnect( hDbc=0:1 )
[0000021425 0000001024] [1032323211.869378 - 09-18-2002 10:26:51.869378]     ---> Time elapsed - +7.550000E-004 seconds
    sqlccsend( ulBytes - 72 )
    sqlccsend( Handle - 1085627784 )
    sqlccsend( ) - rc - 0, time elapsed - +8.800000E-005
    sqlccrecv( )
    sqlccrecv( ulBytes - 27 ) - rc - 0, time elapsed - +5.390000E-003

[0000021425 0000001024] [1032323211.875169 - 09-18-2002 10:26:51.875169] SQLDisconnect( )
[0000021425 0000001024] [1032323211.875226 - 09-18-2002 10:26:51.875226]     <--- SQL_SUCCESS   Time elapsed - +5.951000E-003 seconds

[0000021425 0000001024] [1032323211.875325 - 09-18-2002 10:26:51.875325] SQLFreeConnect( hDbc=0:1 )
[0000021425 0000001024] [1032323211.875394 - 09-18-2002 10:26:51.875394]     ---> Time elapsed - +9.900000E-005 seconds

[0000021425 0000001024] [1032323211.875498 - 09-18-2002 10:26:51.875498] SQLFreeConnect( )
[0000021425 0000001024] [1032323211.875578 - 09-18-2002 10:26:51.875578]     <--- SQL_SUCCESS   Time elapsed - +2.530000E-004 seconds

[0000021425 0000001024] [1032323211.875650 - 09-18-2002 10:26:51.875650] SQLFreeEnv( hEnv=0:1 )
[0000021425 0000001024] [1032323211.875716 - 09-18-2002 10:26:51.875716]     ---> Time elapsed - +7.200000E-005 seconds

[0000021425 0000001024] [1032323211.875886 - 09-18-2002 10:26:51.875886] SQLFreeEnv( )
[0000021425 0000001024] [1032323211.875932 - 09-18-2002 10:26:51.875932]     <--- SQL_SUCCESS   Time elapsed - +2.820000E-004 seconds

[2002-09-18 21:42 UTC] kalowsky@php.net

After looking through your SQL Log, it looks like it can't possibly be what I thought it was (which is good, at least in my end of things <g> ).

Does this happen when you build just --with-ibm-db2=shared and --enable-debug?

[2002-10-08 21:53 UTC] sniper@php.net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Wed Apr 24 23:01:34 2024 UTC