Installation of devel whilst running PHP5 will result in a dead site that returns 500 errors on every page. Uninstalling/removing doesn't help.

If you back PHP down to 4 you will be able to access the site again but even then uninstalling devel will NOT allow you to move forward to PHP5 again.

Comments

esllou’s picture

I would like to add my voice to the growing concern over this module. This module is damaging sites and, in my opinion, needs to be withdrawn immediately until its bugs have been sorted out. I had this happen on a site being created, I dread to think what would have been the chaos caused if it had been a live site.

PLEASE WITHDRAW THIS MODULE IMMEDIATELY!

heine’s picture

Posting a critical bug report without any substantial information is not much help. Then, adding nothing to it with "PLEASE WITHDRAW THIS MODULE IMMEDIATELY!" is not particularly useful.

Focus on a solution.

I use devel 5.x-1.x-dev (// $Id: devel.module,v 1.106.4.39 2007/03/08 06:26:38 weitzman Exp $) on PHP 5.1.4, so PHP 5 on itself is not the problem.

What exact devel and PHP version do you use? Do you get any errors in the Apache log? If Apache is throwing segfaults, you may need to check php.net for a bugfix (eg http://bugs.php.net/bug.php?id=39640).

dan90’s picture

Ok, I can confirm there is a problem.

php 5.2.1/ running as a CGI (on a dreamhost linux box)

devel-5.x-1.x-dev.tar.gz :
// $Id: devel.module,v 1.106.4.39 2007/03/08 06:26:38 weitzman Exp $

devel functions like the devel block and the php execution block work fine.

the bug seems to be triggered after visiting the admin/settings/devel page and enabling the option "Collect query info"

It seems to take a few minutes to fix itself once you've removed devel module... (some kind of poisoned cache issue? it seems so - if you truncate the cache tables it all comes back up. My caching is turned OFF, BTW.)

alpinejag’s picture

I tried that and still can't use Php 5.2.1.

I've erased all files associated with Devel.
Deleted it's tables, and any references in other tables.
Turned off caching and truncated all the cache tables.
Still get the 500 error the second I switch back to Php5.

If I get it working I'll let people know how I did it. (on a Site5 linux box)

FiReaNGeL’s picture

No problems here with 5.2.0, so could it be 5.2.1 specific? Do you absolutely need to run the very latest PHP version (especially if it causes problems?)? Anyway, lets hope we find the source of the problem...

alpinejag’s picture

Sorry, I'm actually running 5.2.0, I was looking at the previous post and typed 5.2.1.

cybe’s picture

Looks like I joined the club.

I had devel enabled, no problem, but the second i really enabled it, by enablebling some settings in it's ettings page the site died. Totally blank page. I have no access to logs. Deleted all reference to devel in the database, deleted the devel module... no help..

came here.

Hope we can resolve this nasty little buggeroo

PHP Version 5.2.1

stop14’s picture

wow. that's crazy. i've just taken down a site that was under critical development. it was fine until i set the query logging features, then everything tanked. i'm trying to root out at what point the system craps out exactly to get a clue as to what's what and i'll see what i can come up with.

still, this is crazy serious. i may have to rebuilt this from the ground up if we can't isolate the problem soon.

wuf31’s picture

I've a similar issue with drupal 4.7.6 and latest devel for 4.7, though I can't confirm that it is a HTTP 500 error, the page just went blank. Nothing in the error log.

For those who scratch their heads trying to get their site back online, this is what I do.
1. Delete anything that starts with devel from the {variable} table.
2. Empty the {cache} table
3. You should be back online.

Hope this help

mo-seph’s picture

Yup, same issue here:

Drupal 5.1, PHP 5.2.1, Devel 5.x-1.x-dev (dreamhost)

I deleted everything from {variables} starting with devel, and everything in {cache}, but no dice.

I've now deleted the three variables starting dev_ and the site's working again.

All I get in the logs is:
[error] [client x.x.x.x] Premature end of script headers: php5.cgi

If there's any more useful information I can post, let me know.

cyberswat’s picture

I had to delete everything devel related in the variables, permissions and system table. Everything remained unresponsive until I called the cron.php page. Nothing gets you going in the morning like having a module take out your site.

esllou’s picture

weeks later, this module is still being downloaded by people who go on to take down their sites. Oh deary deary me. It is nothing short of wilful how this module is being left on drupal.org

Fixing the bug is NOT the priority. Preventing people damaging their sites most certainly is. If Pepsi discovered that their product was poisoning people, would it be left on supermarket shelves, customers vomiting in the aisles, while their scientists attempted to "recreate the poisoning scenario". No, it would be off the shelves in minutes.

I have no doubt this has the potential to be a useful module but at the moment, it is only doing damage and should therefore, and I repeat my assertion from earlier in the thread, taken off drupal.org without further delay.

greggles’s picture

I had this problem on several sites and I finally reduced it to this set of steps:

0. Begin with php5.2
1. Install devel module - and enable the query log so that dev_query = 1
2. Disable devel module - the dev_query variable remains in the variable table
3. Site begins giving 500 errors

To resolve this you can:
run the query: delete from variable where name = 'dev_query';
Then you have to clear the cache_page and/or run cron.php

I was trying to figure out why this variable is active even when devel.module is disabled and I noticed that in the database.inc files there is some code that involves a variable_get('devel_query').

I propose that the solution is to create a hook_disable that unsets this variable and then clears the cache.

@moshe - if you agree with that idea I'd be happy to roll a patch that does so.

greggles’s picture

Actually - step 2 never happens for me because enabling the collect query information kills the site.

I was guessing at steps based upon a site that had been upgraded from 4.7 where devel was enabled in 4.7...

I guess I'm still investigating causes and solutions.

greggles’s picture

Priority: Critical » Normal
Status: Active » Closed (won't fix)

OK - it appears that there is a problem with Zend optimizer 3.2.5 and below http://www.zend.com/forums/index.php?t=msg&goto=9178&S=0c34c6f97dd6a7957...

I've confirmed this on two sites now (one with ZendOptimizer 3.2.0 and one with 3.2.2) though I didn't yet get to upgrade them to 3.2.6 to see if it would go away.

I'm downgrading this and marking status "won't fix" (since there's nothing to fix) until we can confirm that the problem is related to Drupal and not just zend optimizer.

To the people who posted rude messages about devel module breaking your site - perhaps you are ready to apologize and can then go complain to your host/zend?

greggles’s picture

So, we just got a server upgraded to the latest Zend version and it works fine. I think we can confirm that we keep this closed now.

greggles’s picture

Title: Devel + PHP5 = dead site with HTTP 500 errors » disable query logging when devel module is disabled
Category: bug » feature
Status: Closed (won't fix) » Needs review
StatusFileSize
new815 bytes

I discussed this briefly with moshe in irc and he liked the idea from #13 of disabling this feature when devel module is disabled. It's possible that someone could really want to keep that enabled when the module is disabled so my patch sends a message to the user about the fact that it's been disabled.

Tests/Reviews welcome.

johnalbin’s picture

Patch is quite simple. Looks good to me. One more review and then we’ll commit?

greggles’s picture

looks good...aside from the parse error on the variable_set ;)

At least one full test/review should be done...

johnalbin’s picture

StatusFileSize
new656 bytes

parse error…smarse error. The computer will know what you mean. Trust me.

Okay. Okay. Here’s an updated patch without the parse error. But now I can’t review it since I wrote the patch… hmmm.

moshe weitzman’s picture

Status: Needs review » Fixed

committed. thx.

Anonymous’s picture

Status: Fixed » Closed (fixed)
ff1’s picture

Title: disable query logging when devel module is disabled » devel module does not work with old zend version
Priority: Normal » Critical
Status: Closed (fixed) » Active

Since most other bugs about blank screens and 500 errors point here, I thought I'd update this issue. Feel free to create a new issue out of this comment if necessary.

Based on the comment in #15 above, it would appear that it is the zend engine that causes the devel module to kill a site after activation of the 'dev_query' variable from within the settings page. How simple would it be to add a zend_version() check on the settings page which prevents a user from activating that setting if the correct version of zend is not installed (with an appropriately worded helpful message of course)?

I know the tone of some of the early messages in this issue were very harsh, but the fact does remain that 'installing the devel module can kill your site'. It seems to me that it is better to prevent users from using this module in the wrong environment (bad version of zend) than to keep dealing with the questions from irate users who have killed their site.

If the solution above is not viable, then there must be at least a message on the module download page warning users to check their zend version before installing this module.

johnalbin’s picture

Title: devel module does not work with old zend version » zend optimizer segfaults PHP during devel backtrace (white screen of death)
Component: Code » Documentation
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

…it would appear that it is the zend engine that causes the devel module to kill a site after activation of the 'dev_query' variable from within the settings page…

the fact does remain that 'installing the devel module can kill your site'.

Those statements are incorrect.

Devel uses debug_backtrace(), a standard PHP function. Zend Optimizer (versions 3.2.0-3.2.4) causes the debug_backtrace() function to segfault. It is not the devel module that kills a site, it’s Zend Optimizer.

Also, the dev_query variable is part of the database code of Drupal core. The devel module just makes it easier to enable. So making a change to devel isn’t going to prevent the underlying issue.

As to having to “keep dealing with the questions from irate users who have killed their site,” I only see one issue (#147799). What other issues are you seeing?

If this issue does become (or already is) a continuing problem, a note on the project homepage or in the README could be said about avoiding those versions of Zend Optimizer. Might I suggest:

White Screens of Death: Zend Optimizer versions 3.2.0 through 3.2.4 are seriously buggy. You will need to use a newer version of Zend Optimizer when using the devel module.

greggles’s picture

Category: feature » task
Status: Postponed (maintainer needs more info) » Fixed

I modified the project home page before JohnAlbin's post, but I generally agree with you, JohnAlbin.

If anyone thinks that the text is insufficient then please write your proposed text in this issue.

Compatibility Note: The Devel module will not work with Zend optimizer 3.2.5 and below. If you have one of those versions of the Zend optimizer and enable query logging it will break your entire site and may end in a blank screen. To fix the problem see this issue. You can also fix it by upgrading to a more modern version of Zend Optimizer.

johnalbin’s picture

I think the text you used is perfect. Minor bug in the link, though. You forgot the leading forward slash, so the link incorrectly goes to http://drupal.org/project/drupal.org/node/126098

greggles’s picture

Thanks, good catch - fixed.

ff1’s picture

Thanks for updating the project page. That message is just what is needed!

Apologies if I sounded like I was blaming the devel module developers for the problem in my previous post. That certainly wasn't my intention. I fully understand that it is the zend engine that causes the white screens, but to a standard user (eg. me!), their site is working perfectly well until they install the devel module. The message on the project page would definitely have prevented me from installing this module earlier today, so my post has served its purpose.

Thanks again for acting so quickly.
Ian

personman’s picture

There's a quick fix for users like me who can't upgrade their Zend optimizer (I'm on Dreamhost.) Open devel.module and comment out or delete these two lines:

$bt = debug_backtrace();
$query = $bt[2]['function'] . "\n" . $query;

After that it works fine for me. There's no backtrace, but you see the query and the time. Is there a way to check the Zend optimizer version and wrap those two lines in a conditional statement?

johnalbin’s picture

Hi Danny,

I really feel the note on the devel project homepage is sufficient to warn people off. Even with a bad Zend Optimizer, you can still use the devel module, just not the query logging functionality.

yopyop’s picture

Silly me, I got caught by this, have a 500 Internal Server Error and am attempting to uninstall. I'm running Dreamhost shared account, php5.

I'm trying to comment out the code in the devel.module file described by Personman in comment #29 above, to at least restore access to the site. I don't find this snippet of code in any of the files in the module in the current 5.x-1.x-dev version of the module.

If there was a way to check the Zend optimizer statement on install of the module, that would help anyone like me who blindly install the module from making the wrong move.

Thanks

greggles’s picture

The easiest solution is to edit your domain settings on panel.dreamhost.com and set your php version to 4. Then you can disable the query log and uninstall the Devel module, and change the php version back to 5.

greggles’s picture

Also, please put your vote on https://panel.dreamhost.com/index.cgi?tree=home.sugg& for the item "Upgrade Zend to the newest version."

If you are logged into your panel then click on this ink.

Anyone else on DreamHost is encouraged to do the same to help get them to a modern version of Zend so we can stop dealing with this issue. Anyone on another host is encouraged to submit a support ticket requesting Zend optimizer upgrade.

yopyop’s picture

I just want to post an update on my own situation for anyone who is having this problem: after following the instructions on this page in deleting the devel module files, and then every instance of devel in the SQL tables (from people's comments above) and running cron.php, it finally came back. whew.

Thanks for following up on this greggles. I second contacting Dreamhost to upgrade Zend. I should have read the warning on the main page closely before wading in. Thanks for the module and the help.

Anonymous’s picture

Status: Fixed » Closed (fixed)
taqwa’s picture

This is absolute bs. How is a newb suppose to realize what the heck zend optimizer is?! I read your disclaimer and didn't think it was anything that was a part of my site. Now I have to waste time reverting to php 4.2 and uninstalling/reinstalling modules.

greggles’s picture

@lukas2000 If you must complain, at least do it constructively. Please state a positive recommendation of what you want to see done.

I added a comment to the project page saying "Note that this problem specifically affects customers of DreamHost and possibly other hosts." If you are on a different host, then please let us know which so we can add them to the list. Hopefully that will make it simple enough for a "newb" to understand the situation.

kinnel’s picture

Hi, all. I think the Zend version warning is not broad enough.

I am using Hostmonster (sub of Bluehost). I saw the warning on Zend 3.2.5 and checked which Zend version Hostmonster is using: 3.2.8. However, I've had the same problem. I've deleted the devel module, cleared all caches and all table references to devel_(XXX). I've also run cron.php. No luck yet. However, I have yet to call Hostmonster and see if I can use PHP 4.

greggles’s picture

@kinnel - Note that you also need to delete the dev_query variable.

We'll certainly be ready to update the description pending your investigation.

kinnel’s picture

The sneaky little bugger. That fixed it. Thanks, greggles!

eljustino’s picture

@kinnel
I use Hostmonster for my site, too, but don't seem to have this problem. Noticed, though, that the server I'm on still uses PHP v5.1.6 (along with Zend Optimizer v3.2.8).

Maybe you can have them move your account to a server with this older PHP version?

bdimaggio’s picture

I've gotten the wsod when enabling "collect query info" as well, but using Zend Optimizer 3.2.6 and PHP 4.4.7 (I'm on Verve Hosting). Just wanted to enter that data point -- was able to get the site up and running again in short order thanks to all the helpful comments here, esp. Greggles'.

jeff veit’s picture

Title: zend optimizer segfaults PHP during devel backtrace (white screen of death) » Me too
Version: 5.x-1.x-dev » 4.7.x-1.x-dev
Component: Documentation » Code
Category: task » bug

Happened to me too. :-(

I deleted all the devel tables.
I cleared out dev_query from the variables.
I cleared out the cache
Ran cron.php

Still have the white screen of death.

php 5.20
Drupal 4.7
Zend Optimiser 3.2.2,

greggles’s picture

Title: Me too » zend optimizer segfaults PHP during devel backtrace (white screen of death)

Fixing title. I also updated the project home page to reflect the updates from other users who have been bitten by this.

@Smoothstr - sounds like you did most everything right. Can you run your site on PHP4 temporarily to change the settings back?

ica’s picture

Until issue can be fix for people who actvated devel backtrace and got the (white screen of death)
apart from cearing the caches you can deactivate devel backtrace withing phpMyAdmin
steps
open phpMyAdmin select your DB search 'dev_query' and find dev_query on the 'variables' table

and edit the table by changing
------------------------------------

name	value
dev_query	i:1;
to
dev_query	i:0;

that should disable the dev_query

shedevches’s picture

Version: 4.7.x-1.x-dev » 5.x-1.x-dev
Component: Code » devel

Host: Bluehost.com
PHP version 4.4.7
Drupal 5.3
Devel-5.x-1.x-dev

Same problem. Fixed with ica's suggestion (#45)

Hope this helps someone in my situation save some time who might be just as unfamiliar with PHPMyAdmin as myself:

1) BlueHost Control Panel -> PHPMyAdmin
2) From the Databases dropdown list on left, selected my Drupal database (_drp1)
3) Scroll down to Variable
4) On the right side, "Search"
5) Next to name (down the bottom) typed "%devel%" (without quotes), then go.
6) Select edit next to "dev_query"
7) Changed i:1; to i:0;

And my site came back. Crisis over. (1.5 hrs later..)
Didn't need to do the rest of the suggestions (thankfully!)

jacine’s picture

Just wanted to add for anyone using MAMP 1.7.1 - You can disable the Zend Optimizer in MAMP preferences.

cjeanson’s picture

greggles, just so you know (and everyone else who is hosted by Dreamhost), it is currently an active upgrade that is being worked on.

If you are logged into your panel, click on the following link and search for zend. You will find it is being worked on. Hopefully sooner rather than later, I would like to get this going so I can make a custom theme myself...

https://panel.dreamhost.com/index.cgi?tree=home.sugg&current_step=Index&...

gagarine’s picture

you have a problem now with dreamhost?

Dreamhost version of php and Zen Optimiser:

adonis: 12:05 PM# php -v
PHP 4.4.8 (cli) (built: Jan 25 2008 10:01:27)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend
Technologies
with Zend Optimizer v3.2.8, Copyright (c) 1998-2007, by Zend
Technologies
adonis: 12:05 PM# ./php -v
PHP 5.2.3 (cli) (built: Aug 21 2007 17:24:23)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend
Technologies
with Zend Optimizer v3.2.8, Copyright (c) 1998-2007, by Zend
Technologies

greggles’s picture

@cjeanson - that's what I recommended in #33.

In fact, the suggestion page has a "feature" whereby you don't need to be on the voting page prior to voting, so if all the Dreamhost users would just follow this link that would be really handy (I contacted their support team to alert them to this feature prior to posting it here, they felt it was a feature, not a bug, so, I will use it).

Remember, suggest Dreamhost upgrade zen if you are a Dreamhost customer.

seaneffel’s picture

Impacts users developing with MAMP as well.

The warning is not enough. I think the devel module itself should require a test performed against Zend versions before you are allowed to enable the query log, the same way the clean url test must be performed before enabling, to prevent jackasses like me from killing their sites. Granted devel isn't a module that new Drupal users are gobbling up, but there is too much opportunity to make a mistake that takes hours to diagnose and resolve for a new Drupal admin.

greggles’s picture

@seaneffel - patches are always welcome.

seaneffel’s picture

greg, I really wish I the skillset to contribute a patch. I suppose even a little PHP study would help me get over simple stuff like this. But, you know, I'm workin on it.

gaele’s picture

Status: Closed (fixed) » Active

I'm sorry, but this isn't clear (anymore).

The project page says devel is incompatible with Zend Optimizer 3.2.8, and "To fix the problem see this issue". However, the fix in #29 does not apply anymore. Where should I comment out which lines?

Also: if I do not enable query logging will I be safe?

greggles’s picture

@gaele - I updated the note to link to the comment where I provided steps to resolve the problem. I also restructured the comment to make it easier to understand.

And yes, if you do not enable query logging you will be safe.

heine’s picture

I see the comment already recommends running a query. To remove serialized variables from cache, a second query would be easy to run as well, so the recipe would become:

DELETE FROM variable WHERE name = 'dev_query';
DELETE FROM cache WHERE cid = 'variables';
gaele’s picture

If I understand it correctly #13 is about recovering from a WSOD, whereas #29 is a work-around to safely use devel without risking the problem. I was actually looking for the latter (and I thought that was meant by the text on the project page). Anyway, as greggles said not enabling query logging will do.

Eluzion’s picture

I don't see anything called "dev_query" in my database.

In fact, I don't even know where Query Logging is or how I can disable it.

I made a fresh install of Drupal6 and installed this module, but now i cannot access the admin page (or really any other page except the frontpage). I just get a white screen.

Ideas?

littlebeetle’s picture

same here, got the white screen. Good thing it was a dummy site

moshe weitzman’s picture

Title: zend optimizer segfaults PHP during devel backtrace (white screen of death) » zend optimizer segfaults PHP during db_query backtrace (white screen of death)
Project: Devel » Drupal core
Version: 5.x-1.x-dev » 7.x-dev
Component: devel » database system

I don't really know what to say anymore. The mother fuckers from Zend are putting out a shitty product and appear not to care. See http://www.zend.com/forums/index.php?S=a9e20fb42ad16fc36f09a5487b092156&.... In order to file a bug with Zend Optimizer, you have to *email* them. No thanks.

Also, this product does not optimize anything (http://www.zend.com/en/products/guard/optimizer/). It *decodes files encoded by their zend guard product*. Thats it. It isn't an opcode cache, or whatever else people expect. If you control your own server, disable this piece of shit in your php.ini.

As you can see, this bug is driving me a bit insane. I'm moving this to the core queue. The line which causes the segfault is in core, not devel. See the call to debug_backtrace() in _db_query(). Devel is only associated in that it provides a UI to enabling the core variable which starts the backtrace(). That variable could be set by any module or in settings.php

Devel_themer also uses debug_backtrace() but then again so do many contrib modules.

-moshe

asd123asd5’s picture

I think that zend optimizer now comes disabled on the latest versions of MAMP, XAMP and WAMP.

jtjones23’s picture

Don't know about the others but zend optimizer is enabled in the default installation of MAMP 1.7.1.

seaneffel’s picture

Ditto, MAMP unpacks with Zend enabled by default.

Anonymous’s picture

Project: Drupal core » Documentation
Version: 7.x-dev »
Component: database system » Admin Guide
Category: bug » task

@moshe weitzman Yes, this is frustrating. However, this is not a Drupal problem, and we shouldn't be modifying code to work around bugs in third-party products.

To fix this issue on shared hosting, put the following in your htaccess or request them to be added to your virtual host:

php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer.enable 0

With that said, I feel that this is simply an issue that needs to be properly documented, and am changing the issue to reflect as such.

gaele’s picture

However, this is not a Drupal problem, and we shouldn't be modifying code to work around bugs in third-party products.

So instead Drupal users should work around those bugs by hand? I don't get this.

I feel like setting the Project field of this issue to "User experience".

seaneffel’s picture

See #51, I think there should be a test performed before use of that feature is allowed, like the clean URL test. Then newbie users don't walk into the trap of either no documentation, poor documentation, or didn't read the documentation. Also a good solution while the "mother fuckers from Zend" aren't playing nice.

Anonymous’s picture

@seaneffel the problem isn't specific to the devel module. You could test for what version of Zend is being used, however, then what? You want to patch core to disable the backtrace for a single use case scenario that can be avoided instead by educating users?

That doesn't make sense.

gaele’s picture

Well yes, I would like to patch core to disable a function that's causing a WSOD. And as Moshe said it's (potentially) not a single use case.

moshe weitzman’s picture

Project: Documentation » Devel
Version: » 6.x-1.4
Component: Admin Guide » devel
Status: Active » Fixed

I found a reliable way to check for this function and disable the collection of queries in this case. Committed to DRUPAL-5 and HEAD. I also issued new releases.

I spit upon Zend for forcing developers to work around their bugs.

gaele’s picture

Amen.

Thank you, Moshe.

seaneffel’s picture

Nice work.

gpk’s picture

Fantastic! Many thanks.

korayal’s picture

my hosting provider upgraded Zend Optimizer to 3.3.0a version but when i try to enable theme developer, it was still giving an error about disabling the zend optimizer.

So i created a php.ini in my public_html folder which includes;

[Zend]
;zend_extension_manager.optimizer = "/usr/local/Zend/lib/Optimizer-3.3.0"
;zend_extension_manager.optimizer_ts = "/usr/local/Zend/lib/Optimizer_TS-3.3.0"
;zend_optimizer.version = 3.3.0a

and now the problem is gone. however i tried the same in another drupal 6 site, which is in another hosting provider and nothing changed (it's zend version was 3.0.1 according to the php info, so i changed the versions in php.ini)

so if you have that kind of access, it's worth a try.

gpk’s picture

On servers where you aren't able to use php.ini then I guess you could always set the dev_query variable by hand and clear the cache table ... if you know enough to get this far then you should be able to fix the problem if PHP segfaults ;-)

Boletus’s picture

Version: 6.x-1.4 » 5.x-1.x-dev
Category: task » bug
Status: Fixed » Active

I used the Devel module to clear the cache when moving a site from development to production.

After that I got a white screen when trying to run update.php. I was on a Host with Zend Optimizer 3.2.2. My host upgraded to Zend Optimizer 3.2.8. Still not possible to run update.php. What can I do to find what is going in behind the white screen? I'm no programmer so be nice :)

RingoDS’s picture

I just voted in my Dreamhost panel for "Upgrade Zend to the newest version."
Hopefully, this will be done fast...

Meanwhile, I still have problems getting Drupal 6 with the devel module to work. Although I am a software engineer, I'm a newbie in the PHP world. I have my hosting on Dreamhost and I added the php_flag settings from #64 to my .htaccess. However, this does not seem to unload the Zend Optimizer php extension from my installation. I still can't activate the Theme Developer module.

Any hints to get up and running would be greatly appreciated!

ardarvin’s picture

I'm hosted with Hostgator (shared hosting). Similar to Hecatomber, I'd like to run the theme developer module, but it complains about having to disable zend first.

I have no idea what version of zend Hostgator is using (I've searched everywhere through their cpanel). Can someone either tell me:

a) how to disable zend
or
b) how to get the devel module to stop complaining about zend, and install the theme developer module for me.

thanks.

Cibby’s picture

Version: 5.x-1.x-dev » 6.x-1.6

I just read the thread and don't know exactly what I should do at this point. I'm a newbie and don't know much about this stuff. I am running MAMP so it has the crappy Zend. I installed devel and it would let me enable all components except the theme builder. When I tried to do that I got the white screen. If I remove the devel folder from my modules folder, my site is fine. If I add it back, I can get back to the modules admin page, but if I try to update which ones are enabled/disabled, I get the white screen again. Basically it looks like I can use my site as long as I don't have devel in the modules folder.

Is there anything I can do to get it working, even if it doesn't have the log function, which is fine by me. I tried installing the most recent version of Zend but that isn't even obvious to me how I put that in the MAMP directory. Any advice would be really appreciated!

Thanks.

carlmcdade’s picture

Run phpinfo() and you will see the optimizer listed in the box with the php engine type

carlmcdade’s picture

Run apachefriends.org XAMPP for MacOSX rather than MAMP. There is no optimizer in the default version of this package.

RingoDS’s picture

A question/remark on the check for Zend Optimizer in the devel module:

AFAIK the module only checks if the Zend Optimizer PHP extension is loaded, but it doesn't seem to do a version check. If I read all the resources on the net correctly, it seems that Zend Optimizer 3.2.8 and up don't segfault Apache anymore, so shouldn't the module work correctly if it can detect that a working Zend Optimizer is installed?

RingoDS’s picture

Breakthrough!

Next to voting for an upgrade of Zend to the latest version on Dreamhost, I also submitted a support request to them. As user gagarine reported, his Dreamhost (adonis) already had version 3.2.8, while mine (boba) only had 3.2.2 so the versions were not in sync between their hosting machines. We are now a few hours later and Zend got upgraded to 3.2.8 on boba as well. I can't complain of the Dreamhost support. :-)

Now the important part: I patched the devel module and removed the checks for the Zend Optimizer php extension. The module got enabled, and as far as I tested now, the Theme Developer module works like presented in the screencast! Target reached!

Some more details:

  • no private cgi-php setup
  • no .htaccess changes
  • PHP 5.2.3
  • This program makes use of the Zend Scripting Language Engine:
    Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
    • with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend Technologies
    • with Zend Optimizer v3.2.8, Copyright (c) 1998-2007, by Zend Technologies

Is it possible for a module to only check the version of Zend Optimizer? If so, is it possible to release a version of the devel module for 6.x to include such a version check?

moshe weitzman’s picture

If someone writes a function to extract the version from the output of phpinfo(), then i will commit it. Zend does not provide a constant for this AFAICT.

Cibby’s picture

I'm not sure if Hiveminds was trying to answer my question in #78, but I'm wondering if there is a solution to getting Devel to work without those changes. Right now my site is fine when devel isn't in the modules directory. It only flakes when I copy it over. I've turned off Zend in my MAMP preferences. I'm assuming there is something lingering from when I had Zend on and enabled Devel. Any suggestions?

ardarvin’s picture

After learning that Hostgator runs zend optimizer 3.2.2, I fired off an email asking them to upgrade. I received this email from Hostgator support:

Since 3.3.0 segfaults as well, i'd recommend 3.2.6, here's how to enable it.

Put this in php.ini file inside your script directory:

zend_extension=/etc/ioncube/ioncube_loader_lin_5.2.so
[Zend]
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.2.6
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.2.6
zend_optimizer.version=3.2.6
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

Put this in your .htaccess in public_html:

AddHandler application/x-httpd-php5 .php

ardarvin’s picture

Now if someone could tell me how to patch/hack devel to bypass the zend check (not that it's ideal...but it'll get me going), that'd be great.

Cibby’s picture

I'm going to share one other oddity in the hopes someone has an idea of how to fix this so I don't have to restart... I am running a local site, have Zend off and delete Devel from my modules directory. My site works fine, but I obviously can't use the Theme tool. When I copy Devel to the modules directory, my site still appears to work fine. I can move around to all areas, except 1) Devel does not how up as a configurable module and 2) when I go to Administer - Site Building - Modules, I first get an error popup saying

http://localhost:8888
There was a problem adding history.

When I scroll down I see Devel, all functions are checked except the Theme Builder. I initially selected it, but I don't think it ever took. I can then try to check Theme Builder or uncheck the others, or I can try to go to the uninstall tab or another page on the site, all of them give me the white screen. Again, I can remove Devel from my modules folder and the site is back to normal, so it seems.

Any ideas?

RingoDS’s picture

ardarvin,

This is what I did to disable the Zend check:

In file devel.module, starting at line 782, comment out this block of code as below:

//  if (extension_loaded('Zend Optimizer')) {
//    $description = t('You must disable the php Zend Optimizer extension in order to enable this feature. Zend Optimizer is <a href="!url">horribly buggy and segfaults your Apache</a> ... ', array('!url' => url('http://drupal.org/node/126098'))). $description;
//  }

In file devel_themer.install, starting at line 15, comment out the block of code as below:

//    if (extension_loaded('Zend Optimizer')) {
//      $requirements['optimizer'] = array(
//        'title' => $t('Zend Optimizer'),
//        'description' => $t('You must disable the Zend Optimizer php extension in order to enable this module. Zend Optimizer is <a href="!url">horribly buggy and segfaults your Apache</a>.', array('!url' => url('http://drupal.org/node/126098'))),
//        'severity' => REQUIREMENT_ERROR,
//     );
//    }

Make sure that you comment out the correct lines, starting with the if-statement upto and including the matching closing parenthesis. You should be fine now!

Cibby’s picture

For anyone experiencing the issue I outlined in my posts, most recently in #87, hopefully this update on how I got it to work will help.

I'm not a programmer by any stretch of the imagination. I finally was able to update Zend to 3.3 in my MAMP setup. That didn't change anything, at which point I asked a programmer friend if he had any ideas. He suggested reading the php error log, which showed:

[22-Mar-2008 15:04:11] PHP Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 762213 bytes) in /Applications/MAMP/htdocs/drupal-6.1/includes/database.mysqli.inc on line 303

Turns out I needed to increase the memory which was at 16M in my php.ini file. After doing so, I no longer got the "http://localhost:8888, There was a problem adding history" error message. I still couldn't enable the Theme Developer even with 3.3 installed. Once I disabled Zend in my MAMP settings, I could enable Theme Developer, and the site seems to be working fine.

RingoDS’s picture

Moshe,

Here is an implementation of the Zend Optimizer version check:

function isCompatibleWithZendOptimizer() {
   $info = '';

   ob_start();
   phpinfo();
   $info = ob_get_contents();
   ob_end_clean();

   // Match the Zend Optimezer version in the phpinfo information
   $found = preg_match('/Zend&nbsp;Optimizer&nbsp;v([0-9])\.([0-9])\.([0-9])/', $info, $matches);

   $major = $matches[1];
   $minor = $matches[2];
   $build = $matches[3];

   if($major>=3) {
      if($minor>=3) {
        return TRUE;
      } else if($minor==2 && $build>=8) {
        return TRUE;
      } else {
        return FALSE;
      }
   } else {
     return FALSE;
   }
}  

This is my very first piece of PHP code ever. You probably can highlight some PHP coding mistakes, errors and alike, and I encourage you to post them. I'd like to learn from my mistakes...

moshe weitzman’s picture

Status: Active » Fixed

committed RingoDS code to all branches. I only made some code style changes. I issued new releases. Thanks much.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

odeno’s picture

Title: zend optimizer segfaults PHP during db_query backtrace (white screen of death) » Only Devel Generate Module Installed
Version: 6.x-1.6 » 6.x-1.7
Status: Closed (fixed) » Active

I've read through most of the details here and haven't seen the same issue I'm experiencing.

Basically after installing the devel-6.x-1.7 package (in a single devel dir), I only see the Devel Generate module to enable under the modules menu. I can't see the devel themer, access node and macro modules to even activate.

I'm using php 5.2.5, MySQL 5.0.51, Apache/1.3.34 Ben-SSL/1.55 under a LAMP config.

greggles’s picture

Status: Active » Closed (fixed)

Please open a new issue for a new problem.

esllou’s picture

Title: Only Devel Generate Module Installed » zend optimizer segfaults PHP during db_query backtrace (white screen of death)

title changed back

gigfish’s picture

Can someone please explain all this in simple non programmer language Im a newby to Drupal installed Devel to see what it is and it has destroyed my site and about a fair amount of work.. i deleted it but no joy... it goes to a blank screen.. so i copied it back into the module file of my ftp and i egt what i have at the below address..

now all i have is www.gigfishenterprises.com and cant access admin or anything and sorry i dont understand a word of the above..

for a newby and all the work i ahve done, lloks to me like a dangerous module,, maybe its not,, but couls one of u generous people out there in drupal world please lend a simpleton a hand..

Kindest and much appreciated..

gigfish

gpk’s picture

@gigfish: looks like you had problems before you tried devel.module? http://drupal.org/node/256120. Suggest you continue the discussion there ...

gigfish’s picture

i didnt have issues b4 devel at all,, i will try your link.. and come back..

gigfish

gigfish’s picture

as fas as i can see this issues is not closed?!

netw3rker’s picture

gigfish:

if you have the ability to run SQL commands against your database, runing the following two statements against your drupal database should help:

update variable set value='i:0;' where name='dev_query';
truncate cache;

just in case your DB doesnt allow users to run the 'truncate' command, you could run this instead:

update variable set value='i:0;' where name='dev_query';
delete from cache;

The long and short of this is that with that variable set, every time a database query happens, a command that crashes php gets called. the simple recovery is to just reset the variable back to the way it was before devel got turned on.

that should hopefully fix things for ya. This thead is pretty much done for, so if you need more help, feel free to message me privately.

-Chris

clevergeek’s picture

Title: zend optimizer segfaults PHP during db_query backtrace (white screen of death) » zend optimizer segfaults PHP during db_query backtrace (white screen of death) & 500 errors

Just thought I'd add that this caught me this weeked, (July 4th, 2008) on bluehost shared hosting with drupal 6.2 via fantastico.

I'm assuming this is still a zend issue, but wanted to add that the notes listed on the download page suggesting that this plugin will check for the error condition's existance to protect your site did not work for me at all, nor did any of the suggested fixes listed in these threads. (including php.ini edits, .htaccess edits, database edits and cache clearing via phpmyadmin, etc). After installing I only received the div tag for this module (viewable from the source, not on the page), and nothing from my site. After manually removing the db entries I could find, I was only ever able to get 500 errors or white screens.

Thankfully the authors mentioned the problem on the front page of the module, so I took some snapshot backups prior to install (which anyone should do before editing a live site, btw!) and could easily restore my site, but seriously, if your plugin is going to nail as many sites as it appears this one has, could we get some bold on that warning instead of just listing it as recommended for 6.x? I've definitely installed other "recommended" plugins with out paying much attention on the assumption that even if they didn't work perfectly, they wouldn't crash my whole site.

I'm no expert, but I have some relatively extensive experience hosting and editing php based websites (although I am quite new to drupal)...and I tried several times (from .sql database backups, via phpmyadmin) because I really wanted to get this plugin working, and had no luck. I've installed something like 60 drupal plugins, all of which that were recommended for 6.x have worked great (as have several of the dev-version plugins)...this is the only one that has caused me any issues.

To the authors...I think this is a fantastic addition to drupal, and it sucks that someone else's problem has borked things up. I hope at some point things will get cleared up.

Cyberflyer’s picture

Status: Closed (fixed) » Postponed (maintainer needs more info)

I'm sitting here with a new installation of Drupal 6.2 (the one that fixes the security settings).

I installed this module -- along with many others -- in order to debug enough to begin to develop my own theme.

I've worked steadily for several days to get the site as configured as far as I have.

When I enabled devel_themer, it completely broke my site 500 errors and no way to get to anything useful.

So I googled a bit, found this thread and have read it.

The Developers seem to thing (a) the issue is basically closed, (b) the issue is basically with Zend and (c) some after the fact work arounds and warnings pretty much solve the problem.

That all may be techically true, but the simple fact exists that a new Drupal user trying to figure out themeing can see the module, install it, turn on the Devel_themer mode and totally destroy his or her website.

I am not entirely a casual user. Nor am I well versed in the nuance of Drupal.

From my point of view being able to download, install, configure and then use a module feature that will destroy your site, force you to go in with PHP My Admin and tiptoe around inside your database, deleting tables and records, FTPing behind Drupal's back, taking out modules and then reconstruct what you can is not a great advertisement for a CMS.

I am using GoDaddy

PHP Version 5.2.5
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519

Having tried various versions of patches and fixes here, I finally took out the entire devel modules from default/all/modules and deleted the tables, including clearing the cache variable.

I am left with this, instead of a working website:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'devel_themer_catch_function' was given in /home/content/e/t/v/etvotenow/html/includes/theme.inc on line 591

About a dozen of those and then nothing on my page.

If anyone is willing to help me sort this out and post something constructive, I'd be grateful.

If I find a solution on my own, I'll post it.

But I have to agree, at the moment, despite the subtleties of causality, with the originator of this thres.

This module is dangerous as hell and should be put in a cage somewhere until it learns how to behave a little less agressively against the user.

Even if Zend Optimizer is the one poking at it with a sharp stick.

Like someone said earlier, it's no fun to wake up to your website exploding.

A noob, most of all, needs stable tools to grok the Drupal system.

Cyberflyer’s picture

P.S.

I should mention that I am running Drupal 6.2 on top of YAML for Drupal and using the YAML theme.

No doubt that has something to do with it.

From a webmaster's POV, the combo is outstanding to provide cross browser consistency and display as well as a robust feature set.

Whether or not the YAML theme has anything to do with this I cannot say for certain.

moshe weitzman’s picture

Thanks for pounding your fist on the table. Very helpful ... The query you need to fix your site was posted a few times here as recently as two before your post. TRUNCATE TABLE cache or DELETE FROM cache. Those delete the theme registry which is where that error comes from. There is no known safer way to do what devel_themer does.

Cyberflyer’s picture

Moshe:

I was not pounding my fist on the table.

I was attempting to point out the user experience of this module.

Don't read fist-pounding when none is being done.

That said, I read the thread before I posted.

I deleted the contents of the cache table.

I deleted the devel tables altogether and removed them from the modules folder.

Oddly, that cleared things up for GoDaddy, but I am still getting a server error.

In my case there is no safe way to get Devel_themer to do anything.

Thoughts?

What can I tell you that would help pin down this bug?

Cyberflyer’s picture

After hours on the phone with GoDaddy, it turns out that after throwing away the the devel module and deleting the tables in the DB and clearing the cache,
I am still left with this:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'devel_themer_catch_function' was given in /home/content/e/t/v/etvotenow/html/includes/theme.inc on line 591

How can I go into the Data base and flip a variable to indicate that my admin account does not try to utilize the devel module?

Cyberflyer’s picture

Here is a keyhole to a solution:

I went to the variable table and browsed through it.

I noticed that devel_themer_log was set to: i:1;

I hand edited it to be: i:0;

Then I was able to get to the site again.

This fixed my error:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'devel_themer_catch_function' was given in /home/content/e/t/v/etvotenow/html/includes/theme.inc on line 591

Now I have to reconstruct my admin password and go in and turn off anything to do with Deve and erase every aspect of its existence from the site.

So, not to pound on a table, I just spent the day recovering from a disaster I should not have had to experience.

All I did was enable the devel module with the YAML theme on and it exploded.

Why is it my fault for not reading this thread that that happened?

DomainManMike’s picture

Well, devel totally wiped out my site also, and I was using an unmodified Garland theme with only these modules: CCK, Views, and dhtml menu. I tried removing the devel diretory and the devel tables from my database, as Cyberfly said above.. now my drupal site is totally broken. I don't get any errors, just empty head and body tags. Hilarious. I'll post again if I figure out how to fix.

gpk’s picture

Suggest you also disable all devel modules by setting their status to 0 (or removing their rows) in table {system}. Also delete everything from {variable} table that begins devel_ (possibly dev_ too). Then clear all the cache tables.

Take a backup first ...

What versions of PHP and Zend Optimizer are running on your server (check phpinfo)?

Also you should have an error log somewhere that tells you the exact error that occurred.

johnalbin’s picture

Title: zend optimizer segfaults PHP during db_query backtrace (white screen of death) & 500 errors » zend optimizer segfaults PHP during db_query backtrace (white screen of death or 500 server error)
Status: Postponed (maintainer needs more info) » Closed (fixed)

@DomainManMike: If you are experiencing this issue, the fix is posted in comment #13 above: http://drupal.org/node/126098#comment-524069

@Cyberflyer: if all you did was enable devel and your site exploded immediately, then you aren't experiencing the bug described in this issue. Since you would have had to turn on the database query logger to experience this issue. You should open another issue so that others reading this (like DomainManMike) can more easily find the solution.

Noyz’s picture

I found this worked by just disabling the zend optimizer extension in MAMP

Mike-K’s picture

I can't believe this is still an issue... Regardless of the work arounds mentioned above, I just got suckered into using this module. Granted, I'm a noob, but come on. Shouldn't this module NOT be referred to in the Theme override content? In MAMP, I turned off Zend optimizer and I only get the White screen of death on the 'modules' page... Please someone help with what I should do now... ANY SUGGESTIONS?

Thanks in advance.

vm’s picture

WSOD on modules page points more to running out of memory. What is your memory_limit set at in php.ini?
Have you checked your apache logs for the error being thrown?

fact: many people use this module without issue. Especially now that the problems were worked out and the incompatibility with zend the zend optimizer found and worked around by not allowing you to enable the module if the old buggy version of zend is present.

johnrafferty’s picture

I was pulling my hair out before reading this. Having experienced some problems with my
site (which is in development and I have numerous backups) so I thought I would
install the Devel module. Turned on Query- something and whoosh - white screen!!

I tried several silly attempts to pinpoint the problem. At first I thought it was the devel module
so I read a lot of posts that mentioned manually disabling it and emptying the cache
but nothing worked. I then had to consider that it might be something else.

A long story short, after pulling my site totally apart, reinstalling, rebuilding database tables
I came across this post. Deleting the offending record from the variable database
was the key!! Wow!

All I can say is thank you so much!!

Now to put my site back together ...jeezz.

John

Mike-K’s picture

Thanks heaps! I got it working. The php.ini solution was the call... Cheers!

dafreak’s picture

I had the same problem, PHP 4.4.7, Zend Optimizer 3.2.8. Just deleted Devel module and ran update.php, and everything back to normal. Have to get silly host to update PHP and Zend.

Cheers,

DaFreak

exorb’s picture

Just a note that might help someone..

When i enabled the 'Theme developer' portion:
I got the 'white screen' (but only in Firefox)

On IE 7 things worked, so i was able to disable the 'Theme developer' and everything returned to normal.

have not looked into what the issue is/was.

update this was issue:
http://drupal.org/node/324332

so some may not have the white screen 'of death' and just a Javascript failure. - google ads or could be anything else having JS conflicts on your page.

note: you should only be running this mod on a development server anyway.

talino’s picture

Just my 2c of fist banging:

I'm new to Drupal and since I've started learning the system I've been totally absorbed by its flexibility. I've been using Wordpress for a long time and have grown accustomed to tweaking PHP, using plugins, learning the innards etc, but Drupal is still a completely different beast and getting even vaguely familiar with it has taken many hours of my time (as I'm sure was the case for everyone here). I've come to trust the Drupal community for providing excellent modules and associated tips and help for newbies. For two weeks it's been only curiosity and fascination for me, as I've assembled on my local machine a site for a private association which started to function and look exactly the way I wanted it to.

Enter Devel. I've read a lot about it, and since I've had some problems figuring out where data was coming from on different parts of my site, I thought I'd see what I could learn from it. The trust that I had in contributed modules that has been built after spending hours with Views, CCK, Content Access, Wysiwyg, Path Auto, Image and numerous others was such that I didn't even think to check out ongoing issues with an unknown module, especially a prominent one which figures often in many "essential modules" lists.

Needless to say, it was a WSOD extravaganza, even after spending a couple of hours frantically clicking through forum posts and bombarding Google with panic-induced searches. I've spent the better half of the afternoon toggling the Zend Optimizer function in MAMP, hunting through tables in PHPMyAdmin and scanning the PHP code in devel.install. This is not something that I thought I would do when starting to learn one of the most popular systems for content management.

Devel is now completely erased, hopefully, and I got my site back. In five years of hacking away at Wordpress, I never had to do so much diving into MySQL just to get a site breathing again as I had in order to save my Drupal system. And I would like to add that Wordpress is open-source, too. My point is: watch "Monty Python Live at the Hollywood Bowl" again. The man selling the Crunchy Frog sweets claims that the ingredients clearly state at the bottom of the box that the candy he produces has frog in it. The policeman replies: "I must warn you that in future you should delete the words 'crunchy frog', and replace them with the legend, 'crunchy raw unboned real dead frog' if you want to avoid prosecution." For newbies such as myself, who are already somewhat disoriented by Drupal's complexity and power, I humbly suggest that the Devel project page display a huge div saying BEWARE, possibly with "font-size: 10em" and "border: 20px solid red". We got enough issues as it is.

Thank you and sorry for the interruption. Remember you were all newbies once.

cdchase’s picture

FYI, this is still an issue with Zend Optimizer+ included in current Zend Server CE 5.5. Disabling Optimizer resolves the problem.