php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #20203 odbc_do() or odbc_exec() Always produces a segmentation fault core dump
Submitted: 2002-10-31 15:06 UTC Modified: 2003-01-19 19:05 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: xmixail at ipnet dot gr Assigned:
Status: Not a bug Package: ODBC related
PHP Version: 4.2.3 OS: sparc solaris 2.8 and 2.6
Private report: No CVE-ID: None
 [2002-10-31 15:06 UTC] xmixail at ipnet dot gr
The odbc driver from openlink software for ms sql 2000 is used.
Note that thru the openlink adminstator all works fine si this lead me to
the thought that this must be a php problem

PHP was compiled with the option --with-openlink (--with-iodbc produces the same)

Symptoms :
       1)  odbc_connect() suceeds and returns  "RESOURCE ID #1"
       2) the odbc_do() or odbc_exec() always produce
           segmentation fault core dumped.
       3) The error is the same if I run from the comand line "php ptest3.php" 
            I guess i can also run from the command line ouside any web server

This is the script (ptest3.php) that produces the error

*********************script start ********************************
<?
 // putenv("LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib");
 // putenv("ODBCINSTINI=/usr/local/bin/odbcinst.ini");
 // this location will be determined by your driver install.
 // putenv("ODBCINI=/usr/local/bin/odbc.ini");
 // odbc.ini contains your DSN,location determined by your driver install
 $dsn="eettn";
 // this is a valid DSN. Can be tested in odbctest
 $user="sa";
 $password="anmaelky";
 $sql="SELECT * FROM tab01 where col01=1";
 echo ("$LD_LIBRARY_PATH") ;
 echo("aaa<br>") ;
        echo("$user") ;
        echo("<br>") ;
        $conn_id=odbc_connect($dsn,"sa","anmaelky") ;
        echo("CONNECTION ID = |") ;
        echo($conn_id) ;
        echo("|\n\n") ;
        flush() ;
//      exit() ;
        if ($conn_id) {
            echo "connected to DSN: eettn\n\n";
            $result=odbc_do($conn_id, $sql) ;
            echo("result") ;
            echo("$result") ;
            if($result) {
                echo "executing '$sql'";
                echo "Results: ";
                odbc_result_all($result);
                echo "freeing result";
                odbc_free_result($result);
            }else{
                echo "can not execute '$sql' ";
            }
            echo "closing connection $conn_id";
            odbc_close($conn_id);
        }else{
            echo "can not connect to DSN: eettn ";
        }
?>

*********************************** script end **********************************


gdb reports

Program received signal SIGSEGV, Segmentation fault.
0xef3f4474 in SQLExtendedFetch ()

Here is the backtrace of gdb
#0  0xef3f4474 in SQLExtendedFetch ()
#1  0xef3f53d0 in SQLExtendedFetch ()
#2  0xef3cbf38 in SQLExtendedFetch ()
#3  0xef3c72e0 in SQLExtendedFetch ()
#4  0xef3c5740 in SQLExtendedFetch ()
#5  0xef3b35d0 in SQLNumResultCols ()
#6  0xef3aca14 in SQLError ()
#7  0xef398060 in SQLDriverConnect ()
#8  0xef3acae0 in SQLExecDirect ()
#9  0xef73ecac in SQLExecDirect ()
#10 0x44050 in zif_odbc_exec (ht=1543480, return_value=0x171cf0, this_ptr=0x0,
    return_value_used=1) at php_odbc.c:1226
#11 0xe65dc in execute ()
#12 0xc6fbc in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at zend.c:812
#13 0x2a374 in php_execute_script (primary_file=0xeffffc48) at main.c:1383
#14 0x276f0 in main (argc=2, argv=0xeffffcd4) at cgi_main.c:778

Best Regards Christos Michail

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-10-31 17:01 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-10-31 17:32 UTC] xmixail at ipnet dot gr
The result is the same after using the latest cvs and here is the output of gdb 5.0 (and the trace back) :

********************** gdb output *********************
Program received signal SIGSEGV, Segmentation fault.
0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so
(gdb) bt
#0  0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so
#1  0xfeff6560 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so
#2  0xfefcc418 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so
#3  0xfefc76a0 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so
#4  0xfefc5af0 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so
#5  0xfefb3584 in SQLNumResultCols () from /usr/local/odbc/lib/sql_st_lt.so
#6  0xfefac7d0 in SQLError () from /usr/local/odbc/lib/sql_st_lt.so
#7  0xfef97d54 in SQLDriverConnect () from /usr/local/odbc/lib/sql_st_lt.so
#8  0xfefac89c in SQLExecDirect () from /usr/local/odbc/lib/sql_st_lt.so
#9  0xff35e72c in SQLExecDirect () from /usr/local/odbc/lib/libiodbc.so.2
#10 0x4c76c in zif_odbc_exec (ht=1811184, return_value=0x1b4760, this_ptr=0x0,
    return_value_used=1)
    at /usr/pkg/php/php4-200210311500/ext/odbc/php_odbc.c:1318
#11 0x10a9e0 in execute (op_array=0x1b6110)
    at /usr/pkg/php/php4-200210311500/Zend/zend_execute.c:1595
#12 0xfdb60 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /usr/pkg/php/php4-200210311500/Zend/zend.c:839
#13 0xd699c in php_execute_script (primary_file=0xffbefaf0)
    at /usr/pkg/php/php4-200210311500/main/main.c:1541
#14 0x10ef8c in main (argc=2, argv=0xffbefb7c)
    at /usr/pkg/php/php4-200210311500/sapi/cli/php_cli.c:695
 [2002-10-31 19:31 UTC] iliaa@php.net
On step #10 could you print the values of:
query and result->stmt
 [2002-10-31 19:45 UTC] kalowsky@php.net
Also can you please turn on SQL Logging so we can see which steps are being processed.  From the looks of it the SQLExtendedFetch is catching an error condition or possibly a need to re-allocate data and refetch furth of data. 


I find it hard to believe that the odbc_exect (a very basic part of any DB layer) isn't working with MSSQL.  What are the types of data you're trying to extract?
 [2002-11-01 06:16 UTC] xmixail at ipnet dot gr
Please i am not too familiar with gdb can you tell me how
I can print query and result->stmt variables in step #10 ?
Bets regards
Christos
 [2002-11-01 09:32 UTC] iliaa@php.net
display query
display result->stmt
 [2002-11-02 07:26 UTC] xmixail at ipnet dot gr
at /usr/pkg/php/php4-200210311500/ext/odbc/php_odbc.c:1274
1274            convert_to_string_ex(pv_query);
(gdb) n
1277            result = (odbc_result *)emalloc(sizeof(odbc_result));
(gdb) display result
1: result = (odbc_result *) 0x1b4a88
(gdb) display result.stmt
2: result.stmt = 0x1b9da8
(gdb) display /s result.stmt
3: x/s result.stmt  0x1b9da8:    "select * from kan_keim"

At this point the query statment is correct
But just before producing the fault is the following :

1305                            if (SQLSetStmtOption(result->stmt, SQL_CURSOR_TY
PE, SQL_CURSOR_DYNAMIC)
5: /u rc = 16
4: rc = 16
3: x/s result.stmt  0x1c5148:    ""
2: result.stmt = 0x1c5148
1: result = (odbc_result *) 0x1b9dd8
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so

I hope this helps you
Best regards 
Christos
 [2002-11-02 14:20 UTC] kalowsky@php.net
I'd still appriciate the SQL Log :)
 [2002-11-03 09:00 UTC] xmixail at ipnet dot gr
How do I activate the SQL log ??
(is it on the PC running MSSQL or on the sun machine ?)
Best regards 
Christos :)
 [2002-11-03 10:04 UTC] xmixail at ipnet dot gr
I dont know if it helps But i send the last part of /tmp/freetds.log

======================
2002-11-03 17:51:27 inside tds_process_default_tokens() marker is e3
2002-11-03 17:51:27 inside tds_process_default_tokens() marker is ab
2002-11-03 17:51:27 inside tds_process_default_tokens() marker is fd
2002-11-03 17:51:27 inside dbresults()
2002-11-03 17:51:27 leaving dbresults() returning 1
2002-11-03 17:51:27 inside dbnextrow()
2002-11-03 17:51:27 leaving dbnextrow() returning -2
2002-11-03 17:51:27 inside dbresults()
2002-11-03 17:51:27 leaving dbresults() returning 2
Sending packet @ 2002-11-03 17:51:27
0000  01 01 00 38 00 00 01 00 73 00 65 00 74 00 20 00   |...8....s.e.t. .|
0010  71 00 75 00 6f 00 74 00 65 00 64 00 5f 00 69 00   |q.u.o.t.e.d._.i.|
0020  64 00 65 00 6e 00 74 00 69 00 66 00 69 00 65 00   |d.e.n.t.i.f.i.e.|
0030  72 00 20 00 6f 00 6e 00                           |r. .o.n.|

Received packet @ 2002-11-03 17:51:27
0000  fd 00 00 fd 00 00 00 00 00                        |.........|

2002-11-03 17:51:27 inside tds_process_default_tokens() marker is fd
2002-11-03 17:51:27 inside dbresults()
2002-11-03 17:51:27 leaving dbresults() returning 1
2002-11-03 17:51:27 inside dbresults()
2002-11-03 17:51:27 leaving dbresults() returning 2
==============================================

Best regards
Christos
 [2002-11-03 18:45 UTC] xmixail at ipnet dot gr
Having recompiled the iodbclib.so with the symbols in it
Here is the new output of gdb Just before the crash


SQLExecDirect (hstmt=0x1c5050, szSqlStr=0x1c4ff0 "select * from kan_keim",
    cbSqlStr=-3) at execute.c:330
330       if (hproc == SQL_NULL_HPROC)
1: pstmt.asyn_on = 0
(gdb) s
338           (pstmt->dhstmt, szSqlStr, cbSqlStr));
1: pstmt.asyn_on = 0
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so
(gdb)
 [2002-11-04 10:27 UTC] kalowsky@php.net
Are you using FreeTDS or iOBDC?  I'm very confused...
 [2002-11-04 10:54 UTC] xmixail at ipnet dot gr
I use iODBC but this is the log that is produced every time
i run php.

I have compiled with
--without-mysql --with-iodbc
Christos
 [2002-11-05 17:10 UTC] xmixail at ipnet dot gr
Not any idea ??
Pleas help !!
I have a customer waiting
Please if you have any idea Let me know

Christos
 [2002-11-05 17:45 UTC] kalowsky@php.net
1) Your sample script and your backtrace do not agree with each other on what is happening.  If you feed me data for another run, I need to know how that script is working.  I can't debug one, when the problem is in an entirely different format/layout.

2) You still haven't provided a SQL Log.  You can enable this in your odbc.ini file, please read up on the odbc.ini for more information.

3) Which version of iODBC?

4) Did you try to connect using the SQL_CUR_USE_ODBC option?

5) Have you tried using an odbc_prepare command to see if that works.  The error you're seeing is happening within the iODBC system, to which I have no access to.

6) Why have you commented out the ODBCINI putenv line?  Thats generally a useful line for anything you're going to do with ODBC. 

This is as much debugging as I can do right now.  My time is rather commited to other projects right now.
 [2002-11-12 15:41 UTC] xmixail at ipnet dot gr
1. The sample script is exactly the same expet run on solaris 8so just the table name is different NOTHING ELSE.
2. here is the trace of SQL :
php ptest3.php
X-Powered-By: PHP/4.2.3
Content-type: text/html
aaa<br>sa<br>
SQLAllocHandle ( ... )
SQLSetStmtAttr ( ... )
SQLAllocHandle ( ... )
SQLConnect ( ... )
SQLGetInfo ( ... )
SQLGetInfo ( ... )
CONNECTION ID = |Resource id #1|
connected to DSN: test
SQLAllocHandle ( ... )
SQLGetStmtAttr ( ... )
SQLGetStmtAttr ( ... )
SQLGetStmtAttr ( ... )
SQLGetStmtAttr ( ... )
SQLGetInfo ( ... )
SQLSetStmtAttr ( ... )
SQLExecDirect ( ... )
Segmentation Fault(coredump)

3. The version of iODBC is 3.0.6 (the latest)

4. I already tried the SQL_CUR_USE_ODBC option and the
result is exacrly the same

5. odbc_prepare produces exactly the same at
SQLPrepare instead of SQLExecDirect (see last line of SQL trace)

6. The variables are corectrly defined and exported in the environment But even if they exist in the php source the result is exactly the same

I tried to compiel all in 64 bites (gcc 3.2) with -m64 But it failed Any idea if this could help ? and how can i compile php with -m64 ??

I would apreciate if you take a look please

Best regards 
Christos
 [2002-11-15 17:59 UTC] kalowsky@php.net
After having spoken with some of the Openlink engineers, and doing my own tests, I don't believe this is a bug at all in PHP, but rather on your side.

I haven't been able to reproduce this on any of the local sun boxes I have to test with either.

Openlink has suggested building a clean version of the library, and testing further with that.
 [2002-11-17 12:11 UTC] xmixail at ipnet dot gr
Hello

I think is very possible that he problem is on my side
Since you have done tests please tell me :
1. The command line that you user for "./configure" php on    solaris
2. The version of php.
3. the version of iODBC you have used
4. The comand line that you used for "./configure" to
   build the iODBC library
5. Any deviations of the php.ini file from the standard one
   provided with the package.

I guess that since you had no problem at all if I configure and compile exactly the same way as you i also must have no problem.

Best Regards
Christos Michail
 [2002-11-17 14:31 UTC] kalowsky@php.net
> 1. The command line that you user for "./configure" php on 
> solaris

./configure --enable-debug --without-mysql --with-iodbc=/usr/local/lib/odbcsdk

> 2. The version of php.

PHP 4.2.3

> 3. the version of iODBC you have used

iODBC v3.0.6

> 4. The comand line that you used for "./configure" to
>    build the iODBC library

wget ftp://www.openlinksw.com/open42/snkozzzz.taz

> 5. Any deviations of the php.ini file from the standard 
>    one provided with the package.

None that delt with ODBC.
 [2002-11-18 05:19 UTC] xmixail at ipnet dot gr
Could you please also tell me which compiler you used on Sun Solaris to compile php?
The Sun c compiler ? or Gnu ? and which version

Regards
Christos
 [2002-11-18 06:31 UTC] xmixail at ipnet dot gr
I did some further investigation and discovered that odbctest (always succesfull) uses the function
SQLFetch()  to retrieve data. But php always uses SQLExtendedFetch() that it fails.
Any idea how i can make php to use SQLFetch() instead of SQLExtendedFetch() ???

Best Regards
Christos
 [2002-11-18 07:11 UTC] kalowsky@php.net
As with everything OpenSource, gcc. :)
 [2002-11-18 07:13 UTC] kalowsky@php.net
What you're asking is an evil thing, but here goes:

In the php_odbc_includes.h file remove the line HAVE_EXTENDED_FETCH from the HAVE_IODBC section of code.  

Problem is iODBC does work with SQLExtendedFetch.  
 [2002-11-18 08:39 UTC] xmixail at ipnet dot gr
Hello again

You mean the file ext/odbc/php_odbc.h ??

By the way the openlink "odbctest" program works with SQLFetch and not with SQLExtendedFetch

Best Regards
Christos
 [2002-11-18 08:57 UTC] xmixail at ipnet dot gr
Hello from Athens AGAIN

WOWOWOWOWOW I am happy 
I removed the line you said from ext/odbc/php_odbc.h
and DAMN it works !!!!!!!!!!!!!

Thanks very much for your help
I anyway think that the bug still exists as fat as SQLExtendedFetch is conserned and has to be resolved in future releases of php (I used 4.2.3)

Best regards
Christos
 [2002-11-18 10:34 UTC] kalowsky@php.net
Can you please submit a bug with Openlink SW the makers of iODBC.  This should work, for all platforms. 

Please submit a bug at 
http://www.openlinksw.com/support/online.htm
 [2002-11-18 13:14 UTC] xmixail at ipnet dot gr
Hello again
I have already submitted a bug on openlinksw
But dont you think that this is a bug of php ?
And by the way what is the difference between the 2 functions ?

Regards
Christos
 [2002-11-18 16:53 UTC] kalowsky@php.net
No because the same code works just fine using iODBC on OSX, FreeBSD, and Linux (i386).  So if anything it's a case of drivers not being properly supported for the SunOS systems.
 [2002-11-19 05:15 UTC] xmixail at ipnet dot gr
Hello there
I have no tried this on freeBSD or OSX
But on suse linux i had exactly the same symptom
and it was resolved the sane way Thats why i suspect that the problem could be in the php code

Regards
Christos
 [2003-01-19 19:05 UTC] kalowsky@php.net
This isn't a bug in the PHP code.  The SQLExtendedFetch basically creates a cursor for examination of the data, rather than have to transfer the data over the network each time.  In ODBC v3 it's called SQLFetchScroll and works a bit better (optimized thats all).  

Honestly I can't reproduce this bug on my end.  What I'm thinking is happening is your database doesn't support the scrollable cursor option, for which I suggest you read in the manual how to change this.  It should make a big difference.

Marking as bogus, as this isn't a bug in the PHP end of things.

 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun May 22 05:05:45 2022 UTC