ID: 20738 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: MSSQL related Operating System: Win2000, IIS-CGI PHP Version: 4.3.0RC2 New Comment:
Closing Previous Comments: ------------------------------------------------------------------------ [2002-12-09 06:25:13] [EMAIL PROTECTED] Beautiful - works nicely now! ------------------------------------------------------------------------ [2002-12-08 10:34:22] [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-12-01 23:46:57] [EMAIL PROTECTED] This seems to be the problem - i suspect. Testing my existing SQL Server based sites with 4.3.0RC2 resulted in many memory access violations and crashes. I believe that I have tracked these down to two different changes made to the MSSQL extension since 4.2.3: 1) In version 1.82 of php_mssql.c there were 6 mallocs that were changed from "emalloc(res_length + 1);" to "emalloc(res_length);". I believe, however, that the code that uses those memory blocks in at least four of the cases required that extra space. This is the code as it is now for two of the changes in 4.3.0RC2: res_buf = (unsigned char *) emalloc(res_length); bin = ((DBBINARY *)dbdata(mssql_ptr->link, offset)); memcpy(res_buf, bin, res_length); res_buf[res_length] = '\0'; It's the setting of res_buf[res_length] illegal, as that would be beyond the bounds of emalloc(res_length)? Also this code (appearing in two of the changes): res_length = 19; res_buf = (unsigned char *) emalloc(res_length); sprintf(res_buf, "%d-%02d-%02d %02d:%02d:%02d" , . . . Since the length of the character string is going to be 19 characters, isn't the sprintf going to write an ASCIIZ ending beyond the size of res_buf? Does the way emalloc() works take care of these problems? Adding the "+ 1" back to these four emalloc() calls stopped one set of crashes. 2) In version 1.83 of php_mssql.c the mssql_query() function was altered from: if ((num_fields = dbnumcols(mssql_ptr->link)) <= 0) { RETURN_TRUE; } to: if ((num_fields = dbnumcols(mssql_ptr->link)) <= 0 && !dbdataready(mssql_ptr->link)) { RETURN_TRUE; } The CVS comment indicates that this change was for "fixing the mssql_query to handle multiple results correct if the first result does not return any data." If I now call mssql_query() with a query that doesn't return any values (like a SQL-T EXEC call), however, PHP will crash (removing the new dbdataready() check eliminates the crash). Michael Sisolak [EMAIL PROTECTED] ------------------------------------------------------------------------ [2002-12-01 02:01:55] [EMAIL PROTECTED] Hi, Just change the user id's and database in the scripts to match your mssql database and run the scripts. The script is self contained otherwise. I was only able to duplicate the problem with ADOdb and PEAR DB. Straight mssql_* works fine. So a one-liner is a bit difficult. Regards, John ------------------------------------------------------------------------ [2002-12-01 02:01:00] [EMAIL PROTECTED] Hi, Just change the user id's and database in the scripts to match your mssql database and run the scripts. The script is self contained otherwise. I was only able to duplicate the problem with ADOdb and PEAR DB. Straight mssql_* works fine. So a one-liner is a bit difficult. Regards, John ------------------------------------------------------------------------ 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/20738 -- Edit this bug report at http://bugs.php.net/?id=20738&edit=1
