|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #39465 zend_strtod not Thread Safe (causes Infinite Loop)
Submitted: 2006-11-10 16:13 UTC Modified: 2006-12-21 12:56 UTC
From: raven7370 at yahoo dot com Assigned: tony2001 (profile)
Status: Closed Package: Unknown/Other Function
PHP Version: 5.2.0 OS: Win32 (XP 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: raven7370 at yahoo dot com
New email:
PHP Version: OS:


 [2006-11-10 16:13 UTC] raven7370 at yahoo dot com
zend_strtod infinite loop

In Short:
What causes the problem:
Script A stores data in a session, creates two images that call Script B that reads the session data to create two different graphs. 

The problem:
During the unserialize of the session data retrieval the zend_strtod function is called, when multiple concurrent threads unserialize the same data there is (in my experience) a 10% chance that:
A: one of the thread crashes (apache error box, main apache thread and other thread still runs)
B: that the zend_strtod function hangs in an infinite loop for both threads. 

The second (the infinite loop) is far worse since both Threads hang and completely maxes out the two CPU?s. Leaving the main Apache thread with so little cpu cycles that any other page request will never finish.

The code that hangs in an infinite loop at the end of the zend_strtod function is:
	for (i = 0; i <= Kmax; i++) {
		Bigint **listp = &freelist[i];
		while ((tmp = *listp) != NULL) {
			*listp = tmp->next;
		freelist[i] = NULL;
	while (p5s) {
		tmp = p5s;
		p5s = p5s->next;

It either hangs in the first while or the second while loop (most of the time on the first).
The reason for the infinite loop is that somehow the next pointer references create a circular loop? every time I have seen it, it is just a two link loop, i.e. A->B and B->A and both threads are affected and looping in the same position.

This is not just on the debug version but also on the stable 5.1.6 and 5.2 binary release files.
Using OllyDbg the code is:

If I circumvent the code execution described above (using the stable binary release files) with a two byte short jmp, I no longer have any infinite loop hanging the server or crashes? BUT apparently a memory leak since I have removed what appears to be a clean up of a linked list.

So this is a really BAD fix? but it is still BETTER then the infinite loop.. don?t you think?

Important note: (apparently only HT / multi cpu/core have this problem)
I have these problems on a cpu with HT, not a true multi core or multi cpu.. but another system with a normal (single core, non HT cpu) does not have the problem.. I think only one thread might be created by php since windows only shows one cpu.

Anyway.. a true fix would be really great since iI have no idea what excluding the above code REALLY means? I am somewhat hoping that when a thread is killed that windows cleans up.. but does it? And even if it does, when is a php worker thread killed?

Btw.. thread safety is ON when this problem occurs.
(and this is as short as i could make it ;)

Thanks for any help!!!

Reproduce code:
Well it?s a thread interaction problem that is very hard to reproduce on command, I tried to create a script that maximizes the occurrence (one php script that sores some random x & y values in an array and that creats html that continuously loads two images from another php script that uses the session data to draw random images..

But with that I couldn?t reproduce the bug at all? the original script gets the data from a mysql database using adodb and the data stored in the session is more complex.. not sure what exactly makes this go off or not and unfortunately I can?t post the original script and database since it is work related :(

But I tried to narrow the problem down as much as I could and hope that someone might have a clue on what goes wrong where?

Expected result:
Well i would expect multiple concurrent session unserializations of the same data to NOT cause the server to die in a horrible infinite loop >_>

Actual result:
well it does.. die.. 
well ok it just hangs with 100% cpu makeing everything else go 0.00001x speed but that makes a server and everything running on it useless :(

i mean apache can't even answer the request for a new plain unrelated html anymore!

thanks for any help!!! and please do help!


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-11-10 20:42 UTC] raven7370 at yahoo dot com
forgot the OllyDbg pics.. not sure if they help, just in case:
original: (problem area is highlighted)
<img src="">

bad quick fix:
<img src="">
 [2006-11-14 06:30 UTC] raven7370 at yahoo dot com
i guess this category fits better...
 [2006-12-01 14:51 UTC]
Reassigned to myself.
 [2006-12-06 18:21 UTC]
Please try using this CVS snapshot:
For Windows:

This should be now fixed in CVS.
Please test the next snapshot and see if you can reproduce it. Thanks.
 [2006-12-14 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2006-12-14 15:03 UTC] raven7370 at yahoo dot com

I will try it out as soon as possible.

Thanks for the help!

 [2006-12-21 12:51 UTC] raven7370 at yahoo dot com

seems to have been fixed.
However i only tried it for a short while and since this isn't a perfectly reproducible bug i can't say a 100% that it's gone.

If i find the same problem occurring again i will post here again.

thanks again!
 [2006-12-21 12:56 UTC]
Great, thanks a lot.
Please reopen the report if you reproduce it again (though, I don't think it's possible).
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Feb 26 08:01:27 2024 UTC