#20203 [Opn]: odbc_do() or odbc_exec() Always produces a segmentation fault core dump

ID: 20203 User updated by: xmixail@ipnet.gr Reported By: xmixail@ipnet.gr Status: Open Bug Type: ODBC related Operating System: sparc solaris 2.8 and 2.6 PHP Version: 4.2.3 New Comment: 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 Previous Comments: ------------------------------------------------------------------------ [2002-11-18 05:19:16] xmixail@ipnet.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-17 14:31:57] 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-17 12:11:32] xmixail@ipnet.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-15 17:59:40] 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-12 15:41:04] xmixail@ipnet.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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20203 -- Edit this bug report at http://bugs.php.net/?id=20203&edit=1