Hello,

I upgraded from beta3 to beta4 yesterday which caused users to not be able to create new profile nodes.
Existing content type 'profile' (content profile) were able to be edited and saved.
New profile nodes when saved would result in a blank screen with the below error.
The node would not be saved at all.

Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error.

We spent 5 hours figuring out what caused new profile nodes to cause WSOD, uninstalling many other modules, working with the server, etc. Then finally remembered we upgraded from beta3 to beta4 of this module. We restored to the broken state, then downgraded beta4 to beta3 and everything went back to normal. (what a relief!!)

I hope this issue may be addressed.
Until then I recommend staying with beta3.

Thank you very much in advance.

Comments

Bilmar’s picture

I upgraded to beta4 on all my test sites and got the same result.

The contrib modules list on these test sites are massive so not sure if Computed Field is not longer not compatible with a specific module, but it is definitely a change in Beta4 that is causing the WSOD.

XiaN Vizjereij’s picture

Subscribe

YK85’s picture

subscribing - confirmed the issue when our site upgraded as well. reverted to beta3 and found this post. was there a major change done recently?

aweisse’s picture

Subscribing.

After the upgrade from beta3 to beta 4 I could no longer create any new nodes. Every attempt caused php5-cgi to segfault.

maddentim’s picture

beta3 resolved for me.

alioso’s picture

Subscribing.

Had to downgrade as well. Took me a while to figure out what the problem was. I was getting a Premature end of script headers: index.php when saving a content profile field (date) associated with a computed field.

BassPlaya’s picture

I also got an error message and could not save new nodes.
On my server it gave me an Oops! Page not found (500.shtml error)
On my local server it gave me this message:

Safari can’t open the page “http://localhost:8888/node/add/mycontenttype” because the server unexpectedly dropped the connection. This sometimes occurs when the server is busy. Wait for a few minutes, and then try again."

After downgrading as suggested above to 6.x-1.0-beta3 everything was normal again.

jarnoan’s picture

chuckbar77’s picture

subscribing - also went through lots of stress with site pages giving WSOD but glad to find this thread and reverted back to beta3 for the time being. I hope this can be fixed in beta4.

pfaocle’s picture

I think jarnoan's right - if you have: if (!$node->nid) node_save($node); in your computed field code, as suggested in the module's README & plenty of topics on drupal etc, PHP farts out with a segfault & the webserver returns a 500 server error.

Removing this line will fix any 500/WSOD errors, but will prevent the use of $node->nid in the computed field, as its not available during "presave" if the node is new. See #414088: Computed fields should compute on $op='presave' and/or $op='validate', comment #44 for details.

See also #988924: remove "if (!$node->nid) node_save($node);" when update to beta4 for notes on the documentation changes between beta3 and beta4.

parasox’s picture

I was also getting this error, so I reverted to my backup of the module (I'm assuming it's beta3) and it fixed my problem.

My computed code calculates an age from a date of birth:

if (!$node->nid) node_save($node);
  $dob = $node->field_model_dob[0]['value'];
        $now = time();
        $then = strtotime($dob);

        $diff = date('Y', $now) - date('Y', $then);

        if($diff < 0)      /* ideally you want to prevent this from happening */
           echo '??? - negative age.';

        if(($diff > 0) && (date('z',$now) < date('z',$then)))
           $diff --;
$node_field[0]['value'] = $diff;
if (is_null($node->field_model_dob[0]['value'])) $node_field[0]['value'] = NULL ;
chuckbar77’s picture

Will there be a beta5 out with a fix?

marktheshark’s picture

Confirming that rolling back to beta 3 restores functionality.

Beta 4 released 2010-Oct-17 and still no fix for this critical issue...

Moonshine’s picture

Status: Active » Closed (fixed)

Well this one should be back to "normal" via {#414088]. We no longer run during "presave" like beta 4 did, so $node->nid should always be available again.

I was surprised to read that if (!$node->nid) node_save($node); is actually used in the README.txt examples. :o That was never running TRUE before the "presave" change (so it was basically pointless) and when things were running in "presave", well, you can imagine the mess. Maybe that had a purpose in D5 before I came on? Not sure.. I'm pulling that line from the README.txt.

Sorry for the hassle...

parasox’s picture

maddentim’s picture

Status: Closed (fixed) » Active

@Moonshine: I just want to be crystal clear on this issue so I have flipped it back to active.

After the debacle with beta4, I pulled the "if (!node->nid)" code from my computed fields which resolved their wsod. Now reading your comment in #14, I am interpreting the situation that I don't need to put it back in if I upgrade to beta5? I have been holding off upgrading because it wasn't pretty before...

feel free to switch back to closed after you confirm. Thanks.

onaryhopkins’s picture

For three days I was unable to access the administer link, when ever I click on it gives the following errors:

On internet explorer I get : internet explorer cannot display page

On Google chrome I get:Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error.

This is the solution provided by hosting company and why it happened.

The issue you experienced is most commonly caused by the update module for Drupal. Why is this? Here is what happens when you try to access the admin backend.

1. The Update module tries to connect to all web sites listed as update locations for your installed modules and the Drupal installation itself.
2. It is common that one or more of those web sites are not accessible at that point (or are replying too slow). Most commonly it is an issue with third party scripts.
3. The Update modules tries to retrieve the information and since it does not succeed in more than 10 seconds - the scripts times out - a blank page is displayed.

I have now disabled the Update module so your Drupal administrator backend will load without any troubles. You can check it.

Hope this will help others as I did not see any solution to this problem here on Drupal.

Thanks.

saurabhk_97’s picture

#17 - This really helped. Disabling the "Update Status" module fixed my "Error 324 - ERR_EMPTY_RESPONSE" error. Before this, I was unable to install any module.

Thanks again.

Regards,

Saurabh

maddentim’s picture

@onaryhopkins @saurabhk_97 - I don't think your problem was related to the issue being discussed here. When you get an error like the google chrome "Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error." it generally means (at least with Drupal) that you had a fatal error in your php and your server did not returning the page it was supposed to. Lot's things can cause it like a simple unclosed parenthesis or bracket. In this case, a change to the module broken things. The update module could cause a fatal error, but I have never run across it. If you are getting one from it running, I would suspect that some other module that it is trying to check the status of is the root cause. Not getting a response from the update server (at Drupal or where ever it looks) should break things.

Generically disabling update status module does not sound like a bright idea to me. Better to find the root cause. Looking in the server error logs can yield a treasure of pointers.

eric.chenchao’s picture

subscribe

onaryhopkins’s picture

@Maddentim,

Update disabling was temp...at least it resolved the problem.

I am not great in drupal --still learning the rope, so what could be a permanent solution or a work around should it happen again.

My experience in the last couple days is:

1. When I added new modules, in a new web site, I was building I cannot access the site and it comes with similar error--I have to go back to the folder and delete all new module(s) added before I can get back the site and access the admin page.

Like Poormanscron module, after I enabled it on drupal 6.22, I cannot access the admin page...

Any workaround on this?

Thanks.

maddentim’s picture

@onaryhopkins: As I suggested, I would look at my webserver's log files to see what errors may be have been recorded. The error message may include the location of the code at which fatal error occurred. Could be lots of things. The error log should point you in the right direction. Often a google search of the error message yields information for others that may have the same issue and how they resolved it.

onaryhopkins’s picture

Thanks Maddentim. I will follow that route.

dqd’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

Due to the Drupal core life cycle policy and security support advisery, Drupal 6 is no longer supported. So issues for Drupal 6 cannot be longer maintained. The project maintainer has asked for closing all D6 issues to clean up the issue queue. Feel free to reopen the issue if required or set it to "needs to be ported" and latest D8 dev version, if the issue discusses a still missing feature which can be implemented in the D8 version.