php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: james dot jones at firstinvestors dot com
New email:
PHP Version: OS:

 

 [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

Pull Requests

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 Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 11:01:30 2024 UTC