ID: 20203
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: MSSQL related
Operating System: sparc solaris 2.8 and 2.6
PHP Version: 4.2.3
Assigned To:
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[2002-10-31 19:31:52] [EMAIL PROTECTED]
On step #10 could you print the values of:
query and result->stmt
------------------------------------------------------------------------
[2002-10-31 17:32:40] [EMAIL PROTECTED]
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 17:01:02] [EMAIL PROTECTED]
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 15:06:24] [EMAIL PROTECTED]
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
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=20203&edit=1
