|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[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
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Oct 25 02:00:01 2025 UTC |
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:695Having 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)