We have same problem with every sql query we tried:

<?php
$conn = odbc_connect("FreeTDS", "user", "name");
$query = "SELECT * FROM systypes";
$result = odbc_exec($conn,$query);
?>

result:
--------
 ALERT - canary mismatch on efree() - heap overflow detected (attacker '127.0.0.1', file '/var/www/test.php', line 3)

Can you please to run the script through valgrind without suhosin 
extension enabled.

Apparently amd64/FreeBSD cannot run valgrind.  I get this when trying to install it:

===>  valgrind-352_7 is only for i386, while you are running amd64.*** Error code 1

Is there anything else that's amd64/FreeBSD friendly I can use?

Would be nice if you try it on some Linux machine.

http://www.bandwidthbuilders.com/valgrind-output.txt

I know that Valgrind output looks scary, but that is actually a clean run.  The dlopen/dlclose stuff is normal.  Are you seeing the same warning on this setup?

Rasmus,

I tested if this same heap overflow would occur on my Linux box (Debian 4.0) by compiling my own very basic PHP 5.2.5 (./configure --with-mssql) w/ Sushosin patch.  The result: same exact error as on FreeBSD.

The original valgrind output I submitted was from the PHP installed via a Debian package.  So I recompiled my PHP again this time without Sushosin patch and ran valgrind again.  Updated output:  http://www.bandwidthbuilders.com/valgrind-output.txt

Let me know if you need me to do anything else.  Thanks.

Again, that valgrind output does not show an overflow.  Either the problem is being masked by the suhosin patch, or it is a false positive.  Trying removing the suhosin patch and do the valgrind check again.

That valgrind output *is* without the Suhosin patch.

I was saying that I first compiled PHP w/ Suhosin patch to make sure it errors-out with the heap overflow as it does on my FreeBSD box and it did.  Then I compiled PHP again this time w/out Suhosin and ran the valgrind which is the output you see in the link.

Sometimes the Zend memory manager hides stuff as well. Could you please try disabling that by setting the "USE_ZEND_ALLOC" environment variable to 0? (Something like "export USE_ZEND_ALLOC=0" should do that). And then re-try to make a valgrind trace. Thanks!

Okay, here is that:

http://www.bandwidthbuilders.com/valgrind-output-nozendalloc.txt

Ok, there we go.  Looks like there is an off-by-one in there.  But looking at the PHP code, it seems ok.

int res_length = dbdatlen(mssql_ptr->link,offset);
...
res_buf = (unsigned char *) emalloc(res_length+1);
res_length = dbconvert(NULL,coltype(offset),dbdata(mssql_ptr->link,offset), res_length, SQLCHAR,res_buf,-1);
res_buf[res_length] = '\0';

So, we aren't going beyond the buffer, it is somewhere in the dbconvert() code writing to res_buf that is off.  Passing in a larger buffer would fix it, but it would be good to understand why dbdatlen() isn't returning the right length.  Is it an encoding issue?  One assumes single-byte encoding and the other multi-byte or something?

Looping in Frank to have a look.

I have encountered a similar problem. When "select" contains 'smalldatetime' or 'datetime' columns.

I am using Debian Sid and php5 php5-sybase.

Can you please try a CVS snapshot on PHP 5.3.0 in about 4-5 hours. I've 
just applied a patch to the code that may fix your problem. 

Alternatively you can try the patch yourself from this URL;

http://cvs.php.net/viewvc.cgi/php-src/ext/mssql/php_mssql.c?
r1=1.152.2.13.2.4.2.3&r2=1.152.2.13.2.4.2.4&diff_format=u

Sorry for not getting this done sooner.  I got a PHP 5.3 snapshot and compiled/installed it and ran it through valgrind with the USE_ZEND_ALLOC env var set to 0 and here is the output:

http://www.bandwidthbuilders.com/valgrind-output-nozendalloc-php5.3.txt

But did you apply the patch Ilia mentions above? Try again using current 5.3 snapshot. (and if that patch still applies, try it..)
btw. That last url to some output you posted is no longer valid..

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".