Hi -

Thank you for reading this. I have over a million hours into this problem already. I would worship the ground you walk on if you can help me solve this problem.

I developed a module on a test server with php 5.1.4 and mysql 4.1.20. It worked great. I found a more reliable host and installed it there and now I get the White Screen of Death whenever I hit submit. When I log in, when I do a search, when I confirm my module choices - WSOD. If I go to the URL in the nav bar and hit enter, it loads. The new server is on php 5.2.5 and mysql 5.0.51a.

Here is what I've been able to ascertain: I have memory_limit at 128M, max execution time at 30, maximum packet size at 16M. The upgrade to mysql 5 seems to be producing some errors but I can deal with them because at least I know what they are.

I have no clue what CGI does or if it relates to the submit function but the old server has CGI/FastCGI and the new one just has CGI.

There is nothing in my error log. Although I don't know what a lot of the functions below do, I'm trying to make my new server configured like my old one. My php.ini looks like this:

memory_limit = 128M

register_globals 0
session.auto_start 0
mbstring.http_input pass
mbstring.http_output pass
mbstring.encoding_translation 0

error_reporting =6143
display_errors = On
post_max_size = 16M
upload_max_filesize = 10M
log_errors = On
magic_quotes_gpc = Off
max_execution_time = 30
max_input_time = -1
output_buffering = 0
register_argc_argv=Off
register_long_arrays=Off
track_errors = On
session.bug_compat_42 = Off
session.gc_divisor = 1000
session.hash_bits_per_character = 5

When I turn off my custom function, everything seems to work. When I reduce my custom function down to just the following:

 <?php
// $Id: mymod.module,v 1.0 1/12/08 

/** Settings form
* This module has no administrative settings
***
* Implementation of menus
*/

function mymod_menu($may_cache) {
	$items = array ();
	$items[] = array ('title' => t('Support Home'), 'path' => 'support', 'callback' => 'mymod_support', 'access' => TRUE);
	return $items;
}


Boom - I hit a white wall with every submit. I'm ready to commit hari kari. Please save me from this awful fate and, if you have any vague idea, share it with me!

Thanks --

Missy.

Comments

missym’s picture

Bounty on this here with more detailed info: http://drupal.org/node/276216

cog.rusty’s picture

I guess you have verified that your memory_limit = 128M setting has effect, by running a phpinfo() inside Drupal's directory, right?

missym’s picture

Good thinking. Yes I did.

dman’s picture

Generally, I'd expect to see a menu_type value there.
And you really should declare the callback function, even if it is just a placeholder. I have seen menus not get built because their destination didn't really exist - as would be the case with that minimal example.

Still nothing that SHOULD cause a WSOD.

Brilliant problem write-up, BTW. .. Not sure yet what the issue is tho.
Narrowing it down that far is indeed helpful.

Any stupid hidden characters? On (stupid) rare occasions I've fount a problem arising from the file-encoding or an invisible control character. This is a desparate guess.

There shouldn't be a problem with cgi/fast-cgi. Occasionally they run in different run contexts (different working directory, possibly different include_path) but nothing that fatal I'd hope.

I suppose you've not been able to locate the actual server logs?

.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/

missym’s picture

Thank you for your ideas, my friend. Server logs show no problems. I have turned off all modules with the exception of the required core modules and mine. I reduced my module to the simplest possible code:

 <?php

Yes, it's empty. Please let me know if you have any other thoughts. The bounty is $100 to you or your favorite charity.

I also changed the theme to out of the box garland to eliminate that variable.

styro’s picture

are you sure this is a "reliable host"? This really sounds specifically environmental, and would need the help of the host to solve.

Maybe you aren't actually getting the actual error logs - has your host confirmed that?

Does your host have any mod_php webservers you could use? That way if the problem persists, you should hopefully be able to at least get some decent 500 error messages in your error log.

Are your php files ASCII? Sometimes (or so I've heard) a unicode marker at the beginning of a file can cause issues.

--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal

missym’s picture

You know, it really sounds environmental to me, too. I had it with Drupal Value Hosting but they turned out to be unreliable. I switched to http://www.ace-host.net/ and they have been so responsive but this isn't their area of expertise. I will ask them about your ideas. The biggest problem is that there are no error messages so I don't have any way to know what the problem is.

cog.rusty’s picture

The problem has been narrowed down a lot.

- If with any other module except this one you can hit "Submit" without getting an WSOD, then it is something about this module or about the environment of this module.

- If using a hex viewer you haven't found any BOM or other unusual character in the php file, then the only other file which remains to be examined is the .info file.

- If moving the exact same module files to the old sever causes no problem, then the problem was not the module itself but maybe the environment of this module (location, file permissions/ownership, whatever)

Another possibility is that nothing is wrong with the module now, but something related has stayed cached in the database. A name conflict, a path conflict... I don't know. I think D6's update.php would clear the cache tables and would rebuild the menu.

missym’s picture

Thank you for the encouragement.

Actually, WSOD is on every submit in the system when my module is turned on and it goes away when my module is off. I will try to find a hex viewer and look for the high bit characters.

When my module is enabled and Drupal processes after I hit submit, I guess it must either be going into my custom module, or it must be looking through one of the tables and, because my module is on, the process is redirected to never never land. When I go to the nav bar in the browser and just hit enter again, the process continues.

I am on version 5.7.

dman’s picture

so either it's causing problems as part of a form_alter callback - which it's just not doing,
or something is interfering with the way that Drupal processes forms.
And as Drupal actually processes form posts by way of a server-side redirect, there's potential for a set-headers problem to break that.

And set-headers ... well they normally display the errors, but they are also normally just broken by whitespace issues.

So, of course, your problem module file has no whitespace at the top of the file ... :-)

Your php.ini APPEARS to be trying to print errors to the screen, but obviously isn't. Maybe try upping the error reporting, and checing that it's really taking effect in phpinfo()
And, for that matter, you can set your own error log in phpinfo. Maybe the details will start showing up there if you do.

About now I'd either start looking at the http transaction (with a tool like fiddler) to see if it was the post redirect causing the problem (which I suspect),
or enable devel.module and start tracing within core to see what the last successful action in the FAPI pipeline was.

.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/

eugsadhu’s picture

I sent you a message using the contact form with my phone number, in case I can help that way more effectively.
As for the payment, provided we solve the problem, I'd ask that it be split among those that have posted so many helpful replies to your post!

missym’s picture

Thanks -- I got your email and I'm sure you could help me over the phone but I am hoping that part of my contribution to fixing this problem publicly is that it is documented somewhat and a variety of solutions are put out. Your friend in Drupal -- Missy.