|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #39460 Crash when using 64-bit fields
Submitted: 2006-11-10 12:44 UTC Modified: 2011-08-20 18:05 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: ben at thelemite dot freeserve dot co dot uk Assigned: kalle (profile)
Status: No Feedback Package: MSSQL related
PHP Version: 5.2.0 OS: Solaris 10
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: ben at thelemite dot freeserve dot co dot uk
New email:
PHP Version: OS:


 [2006-11-10 12:44 UTC] ben at thelemite dot freeserve dot co dot uk
Executing SELECT * queries on tables that contain 64-bit values (such as bigints) cause a seg fault.  Segfault occurs in php_mssql_get_column_content_with_type within php_mssql.c

It's probably system dependent but has been verified on a separate Solaris 10 setup.

Note the following things though:

1) Running queries containing 64-bit fields that do not contain the primary key do not seem to cause the crash, e.g: "SELECT value from TestTable", but individually selecting fields does, e.g: "SELECT id,value".  Bizzarely "SELECT value,id" doesn't cause a crash.

2) There seems to be some weird allocation issues going on that I have not been able to get to the bottom of.  In php_mssql_get_column_content_with_type there is:

case SQLFLT8:
	ZVAL_DOUBLE(result, (double) floatcol8(offset));

If I change it to:

case SQLFLT8:
	DBFLT8 res_buf;
	memcpy(&res_buf, &floatcol8(offset), 8);
	ZVAL_DOUBLE(result, res_buf);

It cures the problem!  But (very bizzarely), the following code still crashes:

res_buf = *(DBFLT8 *)dbdata(mssql_ptr->link,offset);
ZVAL_DOUBLE(result, res_buf);

BUT... It does not crash at the point of reading the data into res_buf.  It's crashes when something is done with the value!  (Possibly FreeTDS is corrupting the stack?).


SunOS 5.10 Generic_118833-17 sun4u sparc SUNW,Ultra-60

PHP 5.1.6 (cli) (built: Oct 26 2006 15:30:54) [same on 5.2.0 as well though]

FreeTDS 0.63

Reproduce code:
Table I have been using for experimenting:-

TestTable {
   id, int
   value, bigint

PHP code to generate crash:-

$link = mssql_connect("MyServer","MyUser","MyPassword");
$q = mssql_query("SELECT * from TestTable");
echo $q;

Expected result:
Resource id #X

Actual result:
nothing (segfaults when run from CLI)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-11-10 12:55 UTC] ben at thelemite dot freeserve dot co dot uk
Just to clarify; it segfaults both in apache mod and cli.  SQL Server 2003 is being used.  built using gcc 3.4.6, and mssql is built-in (not DSO loaded)
 [2006-11-10 12:58 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read for *NIX and for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

 [2006-11-10 13:56 UTC] ben at thelemite dot freeserve dot co dot uk
Firstly I seem to have narrowed it down a little further.  Crashes only occur when the first 64-bit field occurs in column 2 (as in my test table).  If I rearrange the table to something like

TestTable {
   id, int
   value1, int
   value2, bigint

suddenly it doesn't crash anymore.  very, very weird.

anyway, the requested backtrace:-

php_mssql_get_column_content_with_type+0x2b8(6c0178, 2, 604998, 3e, 6140d8, 61357c)
_mssql_fetch_batch+0x244(0, 6037c8, ffffffff, 0, 2, 523858)
zif_mssql_query+0x2a4(2, 604ae0, ffffffff, 6c0178, 2, ffbfed60)
zend_do_fcall_common_helper_SPEC+0x6f0(ffbfee08, ffbfee08, 1, 688e20, ffbfee08, 66d9e0)
execute+0x10c(6418d8, 40, 523818, ffbff0dc, 168, 748c)
zend_do_fcall_common_helper_SPEC+0x204(ffbff1e0, 35ebd8, 1, 6418d8, ffbff1e0, 1)
execute+0x10c(689008, 40, 523818, ffbff3b4, 78, 748c)
zend_do_fcall_common_helper_SPEC+0x204(ffbff3e0, ffbff3e0, 1, 0, 0, ffbff4a8)
execute+0x10c(5fffa0, ffbffc70, 1e8ff0, ffbff4ac, 4, 2279ac)
zend_execute_scripts+0xe0(7c54, 0, 3, ffbff598, 523598, ffbffc70)
php_execute_script+0x260(ffbffc70, 74, 2d00, 74657374, 0, ffbffa48)
main+0xfb8(2, ffbffd0c, ffbffd18, 50bf40, 0, 0)
_start+0x5c(0, 0, 0, 0, 0, 0)
 [2006-11-10 14:32 UTC] ben at thelemite dot freeserve dot co dot uk
 [2007-06-04 02:57 UTC] shayne at syra dot com dot au
Has this been resolved? Im about to run smack bang into this issue?
 [2009-11-09 20:22 UTC] alejandro dot padilla at gmail dot com
is there any solution about this Bug, 
I'm having the same trouble with this,
there is the information of my case:

Server: Dell PE 2970
SO: RHEL 5.3
PHP: 5.3
FreeTDS: 0.64
SQL Server: SQL Server 2005 SP2 On Win2003

Here is an example:

   id, int
   text_field, varchar(10)
   int_field, int
   bigint_field, bigint
   float_field, float

$link = mssql_connect("mssqlServer", "mssqlUser", "mssqlPass");
mssql_select_db("mssqlDb", $link);

$version = mssql_query("Select
From test_table");

while($row = mssql_fetch_assoc($version)){
  echo "\r\n<br><br>";

The httpd error_log trowhs: zend_mm_heap corrupted

PHP crash when I select the float_field...

Thanks in advance...
 [2010-08-19 09:56 UTC]
-Assigned To: fmk +Assigned To: kalle
 [2010-08-19 10:05 UTC]
-Status: Assigned +Status: Feedback
 [2010-08-19 10:05 UTC]
Been some time with this bug report :)

Could you try the latest stable versions of PHP first? Also if it still crashes, then perhaps could you do a new backtrace, containing file names and line number pairs?
 [2010-10-21 12:33 UTC]
-Status: Feedback +Status: No Feedback
 [2010-11-02 17:31 UTC]
-Status: No Feedback +Status: Feedback
 [2010-11-02 17:31 UTC]
Please try using this snapshot:
For Windows:

 [2011-08-20 18:05 UTC]
-Status: Feedback +Status: No Feedback
 [2011-08-20 18:05 UTC]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri May 24 14:01:30 2024 UTC