EntropySink
Technical & Scientific => Programming => Topic started by: ober on October 27, 2010, 10:54:49 AM
-
I run another SMF board using the same version as this one and I have at least one user bitching about getting a blank page after submitting/replying. It seems to possibly be tied to attachments but he's well within the limits for attachments and everything else seems ok. The owner of the site said he hasn't seen any issues so I'm starting to think it is that person.
Any clue what would cause a blank page on a submit?
-
sounds like php timeout. But that is only likely to happen if the $_POST is processing a large file, but you're saying the images are within the required specs...so apparently not (unless your specs are higher then the actual threshold... ie you *think* you can upload 4mb files but php is set to the default 2)
:dunno:
-
The guy that was uploading said all his images were under 60Kb, so I'm pretty sure that's not the issue. And the limit is set at 3MB/attachment, 7MB/post and there haven't been issues with that in the past.
Thanks though.
-
Is the post itself created?
I can think of only a few scenarios:
1) Post was created and the browser didn't follow the redirect
2) The script itself failed to fire up.
Possible for some exit condition (such as die) to be hit but SMF doesn't have a lot of those without some text.
Is the user in question technically versed? Can you get a Fiddler 2 trace? That'd be the best way as you can see what the browser is sending and what the server is responding with.
-
is php logging fatal errors on the server?
-
It seems to be random so not following the redirect doesn't appear to be the issue. Seems smart but probably not smart enough to do a trace.
I did find this in the error log:
[17-Oct-2010 17:48:42] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 2560 bytes) in /home2/ptstecom/public_html/Sources/Subs-Graphics.php on line 415
[17-Oct-2010 17:50:04] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 2560 bytes) in /home2/ptstecom/public_html/Sources/Subs-Graphics.php on line 389
[17-Oct-2010 17:51:27] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 2560 bytes) in /home2/ptstecom/public_html/Sources/Subs-Graphics.php on line 389
[19-Oct-2010 13:17:43] PHP Fatal error: Out of memory (allocated 1835008) (tried to allocate 311296 bytes) in /home2/ptstecom/public_html/Sources/Load.php on line 1607
[19-Oct-2010 13:17:43] PHP Fatal error: Out of memory (allocated 1835008) (tried to allocate 311296 bytes) in /home2/ptstecom/public_html/Sources/Load.php on line 1607
[19-Oct-2010 13:17:44] PHP Fatal error: Out of memory (allocated 2883584) (tried to allocate 19456 bytes) in /home2/ptstecom/public_html/Sources/ManageMaintenance.php on line 189
[19-Oct-2010 19:23:43] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1944 bytes) in /home2/ptstecom/public_html/Sources/Subs-Graphics.php on line 389
[21-Oct-2010 19:52:10] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 2560 bytes) in /home2/ptstecom/public_html/Sources/Subs-Graphics.php on line 415
[21-Oct-2010 19:53:52] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 2560 bytes) in /home2/ptstecom/public_html/Sources/Subs-Graphics.php on line 415
[23-Oct-2010 01:56:47] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1532 bytes) in /home2/ptstecom/public_html/Sources/Subs-Graphics.php on line 415
[23-Oct-2010 02:01:28] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1532 bytes) in /home2/ptstecom/public_html/Sources/Subs-Graphics.php on line 415
So I guess there is obviously some memory issues whether it's just PHP limits or SMF.
-
Quote from: ober on Today at 07:51:17 PM
OK, I have a few more questions:
1) When you get the blank page, does the post/topic still get created?
2) Is it only when creating topics or also when replying?
3) Can you tell me more about these posts (number of attachments, approximate size of post, etc.)?
4) Are you getting any errors?
Thanks!
To me..or the OP?
1) No
2) Only when creating a new topic with pics. If I just send a message, that works normal
3) I started a thread a few days ago " Washed some Brick today. Whats that white stuff?--pics
I had to first post the type, then modify for every pic. Each pic was re-sized to my desktop and
is around 50-60 KB in size.
4) The screen goes blank and on the bottom it says done, but with errors. No indication what they may be.
Hope this helps. Thanks for looking into it for us.
Not sure what to do with that.
-
memory limit of 8MB for php is the default setting, which is fairly stingy. we usually bump this to 32MB in php.ini on our machines.
my uneducated guess is that the attachment uploading code (something in Subs-Graphics.php?) uses memory inefficiently. something like this possibly?
$fp = fopen($upload, 'r');
$contents = fread($fp, filesize($upload));
-
It is probably exhausting memory when it makes the thumbnail.
-
So I can probably just change the memory limits in a local php.ini file and it should go away, yes? Then again, this is a VPS and I might be able to adjust the actual php.ini file.
-
Probably.
-
OK... so now I have a dilemma. Do I edit the core php.ini file or simply put the settings I want in a local version? Editing the core one would require restarting the webserver, right?
-
OK... so now I have a dilemma. Do I edit the core php.ini file or simply put the settings I want in a local version? Editing the core one would require restarting the webserver, right?
That is what graceful is for :D
-
graceful?
-
Apache has a graceful restart option. Unlike restart or stop it will wait for the child processes to finish. It basically restarts the the master processes and then the child processes as they finish their request. Great for changes that need a restart but you are in the middle of your peak traffic.
-
OH, I have no problem restarting late at night. The user base is in the US and I've taken the board down multiple times in the past in the evening.
I was just thinking I could avoid the whole thing if I set a local php.ini file.
-
OK, so I just created a local php.ini file with a few settings and I asked the members to do some testing. We'll see, but I wonder if we have the same problem here because people have complained about stuff like that happening.
-
Ok, so it's definitely the memory issue but my local php.ini file didn't affect it. I put this in it:
memory_limit = 32M
upload_max_filesize = 8M
I'm fairly certain it's the first one that is causing the problem but I threw the second one in just for kicks. I'm still getting the same fatal memory errors from the graphics manipulation file in the Sources doc. Is there another memory setting I should be adjusting or is my local php.ini file just not overriding the core one? I tried editing the core php.ini file but it's read-only and I can't chmod it.
-
I would throw up a phpinfo file in the smf directory to see if it is being affected or not. Can you edit the http.conf file or the conf file for whatever affects that directory? If so you can use "php_value memory_limit = 32M" (w/o ") to override the value.
-
Yeah, I read somewhere about adding that to the .htaccess file. I might try that.
-
yeah..mike's right. verify you settings are taking by viewing a phpnifo(). if they're not, restart the php processes that are serving requests. if that does't work you might be able to set the value in .htaccess or ini_set() in the code.