Only a blank page returned when access blog home page

[kamiyeye]

Pre-requisites

Wordpress 2.8 beta2 installed in a local env. (not sure, but this maybe related, i guess)

Repro Steps

Simply visit the blog home page

Expected Result

Home page is rendered

Actual Result

1. Only a blank page returned
   
2. No error in http response package
   
3. No error log in apache error log file
   
4. No access log in apache access log file

The file

It took me a while to find it is caused by new wp-includes/formatting.php. my blog home page is correctly rendered once i replaced the file with its early version in an old 2.8 nightly build.
I were trying to find code level cause, but there are too many changes and i'm really not familiar with these files.i gave up.
These two files are to be attached, one is from 2.8 beta2, the other is from an early 2.8 nightly version, one week or two weeks ago, i'm not sure.

[kamiyeye]

early version from a nightly build

[kamiyeye]

from 2.8 beta2

[ryan]

[11345] is the biggest change. Are you using svn? Can you merge that change out and try again.

Also, can your try accessing the individual post pages for the posts showing on your home page and see if a particular one is triggering the problem.

[Denis-de-Bernardy]

It sounds like a php memory limit reached issue. How high is that on your system?

[kamiyeye]

Replying to Denis-de-Bernardy:

It sounds like a php memory limit reached issue. How high is that on your system?

It was 16M, now i changed it to 160M, and the home page is still blank.

[kamiyeye]

Replying to ryan:
I tried an individual post, a page, an attachment page and a backend option page, they all leave me a quick blank page with nothing else.
I've never used svn, i can try it tomorrow. It's too late, i have to sleep now.

[Denis-de-Bernardy]

k... could also be a fatal error with display_errors turned off.

[kamiyeye]

Replying to Denis-de-Bernardy:
Come on, i'm doing theme developing all day, how can i turn off it? It's on, all the time

[kamiyeye]

Replying to kamiyeye:
ryan, i replaced formatting.php with its 11345 version as you said. It's fine, works well just as the earlier nightly build version

[kamiyeye]

Replying to ryan:
Should reply to you, but replied to myself...

[ryan]

formatting.php minus 11345

[ryan]

Replying to kamiyeye:

ryan, i replaced formatting.php with its 11345 version as you said. It's fine, works well just as the earlier nightly build version

That narrows it down to any change from 11345 on. Try formatting.3.php, which is the latest formatting.php with only 11345 reverted.

[ryan]

Setting to blocker until we can figure out what's up.

[ryan]

It could be an infinite loop. Those usually die leaving no trace in the logs.

[kamiyeye]

Replying to ryan:

hey ryan, i did everything you said, and much more. So after a half afternoon's trouble shooting, i think i found the root cause.

Let's first look at line 169 in formatting.php of the old version(works well), the function seems_utf8:

function seems_utf8($Str) { # by bmorel at ssi dot fr
	$length = strlen($Str);
	for ($i=0; $i < $length; $i++) {

and line 190 in latest version:

function seems_utf8(&$str) {
	$length = strlen($str);
	for ($i=0; $i < $length; $i++) {

There is an & added, OMG... yes i use this function in my theme.
After i removed the & from the latest formatting.php, everything is on track now.
It might be a type mistake, i guess, a deeply hidden bug, am i right?

[dd32]

What are you passing into the seems_utf8 function?

The & mearly means to pass a reference to the string, rather than a copy of the string..

[ryan]

Does is_string() return true for what's being passed? Maybe we need a is_string() check at the top for extra safety?

[ryan]

We might want to drop the ref from 2.8 and look into adding it back for 2.9, just to be safe. Figuring why this is happening would be preferred, though. :-)

[westi]

Replying to ryan:

We might want to drop the ref from 2.8 and look into adding it back for 2.9, just to be safe. Figuring why this is happening would be preferred, though. :-)

Adding is_string sounds like a good idea.

We do need to know what is being passed in here though really. Maybe the reporter can attach some examples of what is being passed to seems_utf8, afterall the refernce should make things better not worse.

Also good to know enigronment details - PHP version etc

[ryan]

Patch, in case we decide to remove the ref.

[kamiyeye]

sorry to back later, i didn't think there are still questions. now paste my codes on, maybe a little late cos i saw the patch, but i think some of you may like to view it anyway, and i believe you will know at a glance why it happened:

......
$text = substr($input, $start, $length);
$len = strlen($text);
	
if( $len > 0 && !seems_utf8($text[$len - 1]) ) {
		
	for( $i=0; $i<3; $i++) {
			
		if( $len < 3 ) return '';
				
		if( !seems_utf8($text[$len - 3].$text[$len - 2].$text[$len - 1]) ) {
			$len --;
......

Glad to know the ref is removed, as you can see, if it is added, no matter how i change my codes, my function will not work as desired, i'll have to make an old-version seems_utf8 copy in my theme.
Great patch, great work! And again, your quick reply and responsible work impressed me, you are awesome!

Best Regards,
Kami

[ryan]

(In [11518]) Don't pass by reference. Props kamiyeye. fixes #9994

[Denis-de-Bernardy]

Replying to kamiyeye:

sorry to back later, i didn't think there are still questions. now paste my codes on, maybe a little late cos i saw the patch, but i think some of you may like to view it anyway, and i believe you will know at a glance why it happened:

Just FYI, strlen and substr are not multibyte safe unless overloaded.

[kamiyeye]

Replying to Denis-de-Bernardy:

yes i know, thanks anyway.