|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35428 crash when using mysqli with MySQL 5.0.16
Submitted: 2005-11-27 21:12 UTC Modified: 2005-12-01 12:23 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: marcing at smlw dot pl Assigned: georg (profile)
Status: Not a bug Package: MySQLi related
PHP Version: 5CVS-2005-11-28 (snap) OS: WinXP SP2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: marcing at smlw dot pl
New email:
PHP Version: OS:


 [2005-11-27 21:12 UTC] marcing at smlw dot pl
Windows XP SP2
Apache 2.0.48 / 2.0.55 (not relevant)
MySQL 5.0.16
PHP 5.0.3 /5.1 (not relevant)

Important: Problem is related to MySQLi when using MySQL version 5 only, it doesn't occur with version 4.

Reproduce code:

$db = new mysqli(...);

if($stmt = $db->prepare('SELECT SUM(visitors) FROM core_stats')) {



The problem occurs when using SUM() in query, endless loop seems to start when $stmt->bind_result($total) is invoked and as a result Apache crashes.

Database reproduction code:
CREATE TABLE `core_stats` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `day_of_week` int(1) unsigned NOT NULL default '0',
  `day_of_month` int(2) unsigned NOT NULL default '0',
  `m` int(2) unsigned NOT NULL default '0',
  `y` int(4) unsigned NOT NULL default '0',
  `visitors` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`)

INSERT INTO `core_stats` VALUES (1, 2, 5, 7, 2005, 1);
INSERT INTO `core_stats` VALUES (2, 3, 6, 7, 2005, 6);
INSERT INTO `core_stats` VALUES (3, 4, 7, 7, 2005, 7);
INSERT INTO `core_stats` VALUES (4, 5, 8, 7, 2005, 1);

Expected result:
It should work as it worked on MySQL 4. 

Actual result:
Internal Server Error


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-27 21:20 UTC]
I can't reproduce it.
Can you try it on an *nix OS ?
 [2005-11-27 23:25 UTC] marcing at smlw dot pl
Unfortunately i cannot reproduce it on unix at the moment (have to upgrade the mysql), but 
ill gladly provide further information on windows.
hint: it is essential to create a table with content, im not sure if i provided enough of it;)
 [2005-11-27 23:28 UTC]
You don't have to *upgrade* it, you can install as much MySQL servers/clients as you want if you place it in different directories.
 [2005-11-28 01:22 UTC] marcing at smlw dot pl
Im sorry, but i tried for 2 hours and i cant get mysqli to work under linux, winxp will have to be enough:(
 [2005-11-28 01:25 UTC]
Please try using this CVS snapshot:
For Windows:

It's very much likely that this was already fixed.
 [2005-11-28 12:29 UTC] marcing at smlw dot pl
It seems that whole mysqli code has to be revised, since it still is very unstable, i think that other queries cause the crashes too, like some inserts for example...
the SUM crash is not fixed in latest snapshot, and it seems that there r many more bugs and i still can't get my app to work (its using mysql heavily), i still get crashes and strange behaviours.
If any developer is willing i can provide him with the code of this app so he can see what im talking about.
Just write ur e-mail and ill contact u.
 [2005-11-28 12:33 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

We're still unable to reproduce it.
 [2005-11-28 12:53 UTC] marcing at smlw dot pl
Thats the code to reproduce the crash:
Its used with this table -
But i dont think thats the only piece of code that causes the crash.
just run http://localhost/test.php, then hit f5 and u should encouter it. (i can be only win platform related)
ill do some further research in the meantime.
 [2005-11-28 12:55 UTC] marcing at smlw dot pl
Its not happening when using mysql ext, so im pretty sure its mysqli.
 [2005-11-28 13:06 UTC]
Works fine on Linux with MySQL 5.0.13.
 [2005-11-28 13:15 UTC] marcing at smlw dot pl
Here's there crash itself -
It takes 100% of CPU and then the crash...
 [2005-11-28 13:18 UTC]
As you may understand, the screenshot is not a backtrace and doesn't help in any way.
 [2005-11-28 13:18 UTC] marcing at smlw dot pl
Maybe >= 5.0.15 mysql is required? or maybe it is only windows platform issue.
 [2005-11-28 13:20 UTC]
Yeah, I'd appreciate if you find answers for these questions.
 [2005-11-28 13:20 UTC] marcing at smlw dot pl
Im not sure how to help You, what else can i do?
 [2005-11-28 13:24 UTC]
1) Try to downgrade MySQL on Windows and see if it changes anything.
2) Try to upgrade MySQL on Linux and see if it changes anything.
This is so obvious, isn't it?
 [2005-11-28 14:32 UTC] marcing at smlw dot pl
php 5.0.3 + mysql 4.1.7 - ok
php 5.0.3 + mysql 5.0.16 - crash
php 5.0.5 + mysql 5.0.15 - crash
php 5.1 + mysql 5.0.16 - crash
php 5.1.2-dev + mysql 5.0.16 - crash
php 5.1.2-dev + mysql 4.1.15 - ok
php 5.0.5 + mysql 4.1.13 - ok

Thats all I can tell u for now.
 [2005-11-28 14:40 UTC] marcing at smlw dot pl
These were 3 machines.
 [2005-11-28 15:20 UTC] marcing at smlw dot pl
I dont know if its relevant, but i get exactly the same gdb backtrace as here
 [2005-11-28 15:21 UTC] marcing at smlw dot pl
Now im sure its irrelevant, sorry.
 [2005-11-28 15:27 UTC] marcing at smlw dot pl
I forgot i was running mysql 4.1.15:)
The backtrace from php 5.1.2-dev and mysql 5.0.16:

Program received signal SIGSEGV, Segmentation fault.
0x00e654de in ?? ()
(gdb) bt
#0  0x00e654de in ?? ()
#1  0x00000021 in ?? ()
#2  0x00374128 in ?? ()
 [2005-11-28 16:11 UTC]
If you'd install the latest CVS snapshot and the debug symbols, you'd propably get a bit better backtrace: 

(c) Jani
 [2005-11-28 18:00 UTC] marcing at smlw dot pl
What do i do with these *.pdb files?
 [2005-11-29 01:54 UTC]
Extract them? And copy wherever you have the binaries and dlls for each file..
 [2005-11-29 01:55 UTC]
Assigned to the maintainer.
 [2005-11-30 14:02 UTC]
Please try using this CVS snapshot:
For Windows:

 [2005-11-30 14:45 UTC] marcing at smlw dot pl
What's the point of checking the same and unchanged file again?
 [2005-11-30 14:47 UTC]
No, nothing. Don't bother, it's fixed. And reported by dozen other people too..

 [2005-11-30 14:49 UTC]
Why do you think it's unchanged?
The url is the same, while file is regenerated every time.
 [2005-11-30 15:49 UTC] marcing at smlw dot pl
The size is unchanged, the bug still exists, so where is the difference?
 [2005-11-30 15:56 UTC]
Can't replicate on latest cvs.
 [2005-12-01 10:27 UTC] marcing at smlw dot pl
Right, its better to pretend there is no problem, just stick a label "bogus" and forget.
Why did a have a feeling that u wont care anyway?
In the bug -, georg might have given the reason and possible solution for this problem (my client version is 4.1.7 too).
That could explain why u cant reprocude it.
But its so hard to think...i know...
Its time for u to paste this "Please try using this CVS snapshot:" text, right?
 [2005-12-01 10:37 UTC]
MySQL client bugs should be reported in another place and they are obviously not PHP bugs.

 [2005-12-01 12:16 UTC] marcing at smlw dot pl
But its not the MySQL that crashes, is it?

PDO and mysql extensions somehow dont have problem with different client versions, everything works fine, why mysqli can't?
 [2005-12-01 12:23 UTC] marcing at smlw dot pl
Fresh news - ive updated client version to 5.0.16, and the crash still occurs - only when using mysqli ext.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Mon Dec 11 04:01:27 2023 UTC