UBB.threads PHP Forum Software Community Forums UBB.threads 7 Version 7 Support Random Blank Pages (Wireshark Trace)

Can anyone see anything here that would explain why I'm randomly getting blank pages. I think it's the hosting company problem but I can't pin point the problem and this the best I can come up with. If I wait minute and hit refresh it will receive the page.

GET /ubbthreads/ubbthreads.php?ubb=postlist&Board=10&page=1&PHPSESSID=ef88c70e414f92c81ffa9320682a1e6c HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, application/x-silverlight, */*

Referer: http://meridianunplugged.com/ubbthreads/

Accept-Language: en-us

UA-CPU: x86

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.5.21022; .NET CLR 3.0.04506; MS-RTC LM 8)

Host: meridianunplugged.com

Connection: Keep-Alive

Cookie: ubbt_myid=2; ubbt_key=eaa2f673a9e8530c7b99bb8698452163; MeridianWiki_WIKI_ID=GeorgeMills; PHPSESSID=ef88c70e414f92c81ffa9320682a1e6c; ubbt_mysess=aab9221ab2571018f276769b93ddcb60



HTTP/1.1 200 OK

Date: Fri, 04 Apr 2008 19:32:22 GMT

Server: Apache

X-Powered-By: PHP/4.3.11

Keep-Alive: timeout=5, max=44

Connection: Keep-Alive

Transfer-Encoding: chunked

Content-Type: text/html



0

Don't see anything that stands out. Do you have zlib compression enabled in the control panel? I was working on a site a couple days ago that was getting the same thing with zlib compression enabled. Wasn't just the forums, but other php pages that used it had the same thing.

So, there problem was something with zlib, once they disabled it, it was fine. Host is checking into it now. You might try disabling it and seeing if you still get blank pages.

Thanks but it's off.

Hmm, you might check to see if there is any info in the webserver error logs maybe?

Ok, I think I may have found the problem.

I'm testing a fix now.

@session_start() was failing. Pain in the butt to track this down, I had to sprinkle trace commands to find it.

See PHP Bug http://bugs.php.net/bug.php?id=25876

My hosting company is running 4.3.11
I'm running ubbthreads 7.2.2

I'm trying one of the work arounds suggested in the bug

Fix is adding one line of code below to ...\lib\ubbthreads.inc.php
.
.
.
// ----------------------
// Start the session here
if (!defined('ALTER') && !defined('IMPORT')) {
session_save_path($config['SESSION_PATH']);
@ini_set("session.save_handler","files"); // Added per PHP Bug work around http://bugs.php.net/bug.php?id=25876
$check = @session_start();
header("Cache-control: private");
}

What a pain in the Butt Good Luck

Just wanted to follow up that it does indeed seem to have fixed the problem.

Phew. I had been complaining and complaining to hosting company when it turns out it was not their fault at all.

Thanks for sharing

Lol, well, technically it wasn't the UBB; just a simple bug in PHP which would have been fixed by upgrading (or in this case, hacking the offending file(s))

Sorry I didn't think it was so funny. It was a royal b%%ch to find.

It wasn't a "simple bug" when you have very little control over the host, no tracing and no error report from the app.

I could switch to PHP 5 host but that could easily expose other issues. And the only place I previously saw the "blank page" problem was under PHP 5.

I think UBB could make debugging through HTML easier and more sanity checking. A total blank page for this major failure made it really hard to find.

I also don't like blindly upgrading until things work, I like to get to the bottom of things.

I wasn't laughing at the bug; I was laughing at you taking blame away from the webhost when it's a bug that'd be fixed by upgrading the service... PHP4 goes beyond PHP4.3.11, in fact, the final version is 4.4.8; so they could retain PHP4 while running the final version in its release tree.

and in any case, your fix seems to be to use iniset; which could just as easily be included in the php.ini on the webhost to "fix" it for all users without it being an issue...

And I'm not sure how well the ubb would be at displaying this error as the error was stopping the preprocessor from running, or rather spewing an error... Then again, if there was an error generated, it'd also be in your error logs on your server...

There is no trace that the bug was even fixed in PHP 4 that I could tell. Bug was never assigned or acknowledged.

I just noticed a few folks reporting it against PHP 5.2.5