Add hook_requirements() for buggy versions of eAccelerator

Giving this a better title based on #916312: DatabaseConnectionNotDefinedException error meet during installation (which I am marking as a duplicate).

Are you installing completely from scratch or are you using a settings file from some previous installation (of either Drupal 6 or Drupal 7)? If you already have a settings file, then is there a $databases or $db_url variable already defined there, by any chance?

Besides that, there are a number of places this could come from, I think. If you have (or anyone else experiencing this has) the ability to provide a backtrace, for example using http://php.net/manual/en/function.debug-backtrace.php at the point where the error is generated, that might be very helpful.

I install drupal 7 on a virtual host, on which I have ever installed drupal 6.

Before I install drupal 7, I removed Drupal 6, as well as old database. Then I tied to install D7 from scratch, but I'm not sure how to check whether $databases or $db_url are already defined there.

I tried to use backtrace to dump more information. Since I'm not familiar with php, I'm not sure whether this is what you want:
Please check attached for detailed dump information.

final protected static function openConnection($key, $target) {
if (empty(self::$databaseInfo)) {
self::parseConnectionInfo();
}

// If the requested database does not exist then it is an unrecoverable
// error.
echo "\nopenConnection($key, $target)";
var_dump(debug_backtrace());
if (!isset(self::$databaseInfo[$key])) {
throw new DatabaseConnectionNotDefinedException('The specified database connection is not defined: ' . $key);
}
... ...

Yup, that is perfect, thanks!

So looking at that it seems the problem comes from this code in drupal_get_filename():

  // Verify that we have an active database connection, before querying
  // the database. This is required because this function is called both
  // before we have a database connection (i.e. during installation) and
  // when a database connection fails.
  else {
    try {
      if (function_exists('db_query')) {
        $file = db_query("SELECT filename FROM {system} WHERE name = :name AND type = :type", array(':name' => $name, ':type' => $type))->fetchField();
        if (file_exists($file)) {
          $files[$type][$name] = $file;
        }
      }
    }

Somehow the two of you are hitting that db_query(). The code looks suspect to me to begin with (it says it's trying to check that there is a database connection, but all it really checks is that a function exists). However, I can't figure out exactly what triggers it, because when I run the installer (and seems to be the case for most people), the function_exists() returns FALSE there and the problem doesn't happen. There must be some code path that takes you there, though.

Not sure the best fix at the moment - perhaps it's just as simple as having the code check the global $databases array (to make sure a database connection is defined) in addition to the function_exists().

Not sure this is really the correct or complete fix, but I bet it will solve the immediate problem for you.

I applied "database-connection-914742-5.patch", it works, but after filling database information, below error message come out.

PDOException: SQLSTATE[HY000]: General error: 1 no such table: drupalvariable: SELECT value FROM {variable} WHERE name = :name; Array ( [name] => install_task ) in install_verify_completed_task() (line 783 of /home/drupal7/includes/install.core.inc).
The website encountered an unexpected error. Please try again later.

This is almost the same as what you observed, but I'm not quite catch up what you mean. Could you give me more detail?

Thanks for testing. I think you both might want to make sure that you start fresh when testing this (in other words, delete and recreate your old database, and start with a fresh copy of the Drupal 7 code with the patch applied before you start the installation). Not sure if that has something to do with the followup bugs you saw.

However, I just realized something. The entire code I changed in my patch above is in a try-catch block, so the exception should have been caught. Something else strange is happening here. I vaguely remember another issue (can't find it at the moment) where weird bugs occurred depending on where in the file the custom exception class ("DatabaseConnectionNotDefinedException" in this case) was defined - if it wasn't defined at the top of the file before it was used, weird things happened.

I wonder if that's what's happening here too. I don't have time at the moment but I'll try to track that other issue down later.

I just delete old database and create a new one; copy default.settings.php to setting.php, and reinstall, but the same PDOException error met. And then I checked my setting.php, found something strange: my host is using MySQL 5.0.45, but in setting.php, it is displayed as sqlite. I'm wondering if this is correct?

$databases = array (
'default' =>
array (
'default' =>
array (
'driver' => 'sqlite',
'database' => 'xxxxx',
'username' => 'xxxxx',
'password' => 'xxxxxx',
'host' => 'localhost',
'port' => '',
'prefix' => '',
),
),
);

The issue I was thinking about above was #686596: Child before parent class definition order breaks some opcode cachers.

It looks to me like the same bug occurs here - I'm not totally sure if it's what's causing your problem, but it's a bug anyway, and it's worth a shot. The attached patch moves the definitions of DatabaseConnectionNotDefinedException and other custom exceptions to the top of the file so that they are defined before they are used.

If you have a chance, can you test this patch also? Thanks.

I'm also bumping this to critical. If two people are independently experiencing this now, that suggests there will be a lot more who will experience it later.

I've no idea why #10 would be an issue except for a bug in the PHP engine or opcode cache. Of course, neither of those is bug free, so if #10 manages to dance around engine bugs I am OK with it. :-)

I still don't know how that could even happen though, without a major engine bug.

I applied patch in #10, and the issue is still there:

PDOException: SQLSTATE[HY000]: General error: 1 no such table: drupalvariable: SELECT value FROM {variable} WHERE name = :name; Array ( [name] => install_task ) in install_verify_completed_task() (line 783 of /home/jczuo/domains/soqu.cn/public_html/drupal7/includes/install.core.inc).
The website encountered an unexpected error. Please try again later.

I then remove setting.php, and start a new installation, and noticed that during the install step "Set up database", my database(mysql 5.0.45) is detected as "Database type *: SQLite", then this PDOException come out again.

jczuo: To clarify, do you have MySQL installed, and more importantly do you have PDO and PDO_mysql installed? Those are both PHP modules that are required. (That's how Drupal detects the DB.) If you try to connect to an SQLite database with MySQL-style credentials I'm not surprised it dies. :-)

Downgrading until someone can reproduce the problem in a controlled environment.

For now, we don't know what triggers that.

The most likely cause is something in the lines of #779482: Installation failure when opcode cache is enabled: the settings.php file being cached by a mis-configured opcode cache.

We know exactly what is causing this (or at least part of it) - see #686596: Child before parent class definition order breaks some opcode cachers.

I have some ideas on what else might be happening here (as it seems the above patch helped @jczuo get further in the installer, but does not fully solve the problem) but need to look a little more carefully and don't have time at the moment. Will look into this a bit more later.

It feels *very* unlikely those two are related.

The exception is *supposed* to be thrown in DatabaseConnection::openConnection() during the early stages of the installation when the settings.php is not configured yet.

The try/catch block in drupal_get_path() ignores that error and continues. Other places obviously don't.

So we have two hypothesis:

• Either the try/catch block doesn't work in drupal_get_path()... the exception is properly triggered but is not caught by a catch (Exception $e) block
• Or the exception is thrown in a different code path

Which hypothesis sounds more probable to you? That PHP is completely broken on this environment, or that the exception is thrown in a different code path, and that the stack trace produced in #3 just recorded the wrong exception?

We need more info on how to reproduce the problem.

#779482: Installation failure when opcode cache is enabled sounds to me like the most probable cause (settings.php being cached by the opcode cache and not refreshed).

Damien, I don't understand. The var_dump() in #3 should catch any code path that hits that function. Under what conditions do you think it wouldn't?

Anyway, I was also basing some of my optimism on the fact that the above patches appear to have solved the original reported problem :) I guess it could be a coincidence, and instead some other opcode cache problem.

To clarify, there appear to be three issues here:

1. The DatabaseConnectionNotDefinedException that prevents getting past the choose language screen. Appears to be fixed by the patch in #10.
2. MySQL not showing up as a database option. As Crell said, that one is probably a server configuration issue.
3. It's true that typing MySQL credentials into an SQLite database isn't expected to work :) However, it isn't expected to fail with a PDOException either. It should trigger a form validation error instead. So I don't understand:
   • Why the form validation isn't catching it.
   • Following that, why install_verify_completed_task() doesn't catch the PDOException itself - it certainly has code to do so.

Testing out a theory. @jczuo, if you get a chance, can you try the attached patch (again on a fresh installation)?

My prediction is that you'll still get an uncaught exception when you submit the settings form, but it will come from the install_database_errors() function instead, and will have something to do with "Failed to connect to your database server".

If that doesn't happen, then I don't understand what's going on here.

David, in #3 the first time a DatabaseConnectionNotDefinedException was (legitimately) triggered, the var_dump() output content on the page preventing the redirect.

The issue of the original poster seems to have been fixed by disabling eaccelerator, which points toward #779482: Installation failure when opcode cache is enabled.

The issue of jczuo seems unrelated. Maybe the server has PDO PECL installed, and this is nothing more then #818374: Add a requirements check error if PECL PDO is being used.

I'm very sure MySQL is installed, but not sure whether PDO and PDO_mysql installed. Can I used phpinfo() to check it, or I have to ask virtual host supplier? Any way, I'll try to find way to double check it.

However, I think drupal installation should be able to check this and give user hints if some important modules missing, right?

I applied database-connection-914742-20.patch in #20 based on original drupal7 files and meet below error after choosing language

DatabaseConnectionNotDefinedException: The specified database connection is not defined: default in Database::openConnection() (line 1566 of /home/drupal7/includes/database/database.inc).
The website encountered an unexpected error. Please try again later.

I'm afraid there indeed some PDO configuration error, below are some PDO information, got by phpinfo(), attached is a fully edition.

PDO

PDO support enabled
PDO drivers sqlite2, sqlite

pdo_sqlite

PDO Driver for SQLite 3.x enabled
PECL Module version (bundled) 1.0.1 $Id: pdo_sqlite.c,v 1.10.2.6.2.2 2007/03/23 14:30:00 wez Exp $
SQLite Library 3.3.16

So, you guys could tell me what should I have my host supplier to do to fix it? Thanks.

If you are using a shared host, inform them that they need to install the pdo_mysql PHP extension. If they are unable or unwilling to do so, then you need to get a better web host because that's seriously a basic component. :-)

Damien: Is there a problem with moving the exception classes around? If that seems to fix things for some people I am OK with doing so; if there's still other issues to deal with after that we can address those.

I'm not an opcode expert so I don't know why any viable opcode cache would have such issues in the first place, but, meh. :-)

I just push my host vendor to install pdo_mysql module, and phpinfo() could confirm it, please see attached.

But then I applied patch in #5, I was given option to select mysql or sqlite. After selecting mysql, I still met：
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'jczuo_61art.drupalvariable' doesn't exist: SELECT value FROM {variable} WHERE name = :name; Array ( [name] => install_task ) in install_verify_completed_task() (line 783 of /home/jczuo/domains/soqu.cn/public_html/drupal7/includes/install.core.inc).

which is almost the same as #6. It seems kratkar had fixed it my disable eAccellerator.
So I'm wondering whether disabling eAccellerator is the final solution, or are there any patches I missed

@jczuo: please give us a proper stack trace of the error you are encountering, without any patch applied.

You can get a proper stack trace by applying the attached patch and restarting the installation (please reset your settings.php by copying default.settings.php over it and empty your target database).

1. new install, only patch in #27 applied, get error message after choosing language:

DatabaseConnectionNotDefinedException: The specified database connection is not defined: default in Database::openConnection() (line 1513 of /home/jczuo/domains/soqu.cn/public_html/drupal7/includes/database/database.inc).
The website encountered an unexpected error. Please try again later.

2. then apply patch in #5, get error after set database:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'jczuo_61art.variable' doesn't exist: SELECT value FROM {variable} WHERE name = :name; Array ( [name] => install_task ) in install_verify_completed_task() (line 783 of /home/jczuo/domains/soqu.cn/public_html/drupal7/includes/install.core.inc).

But I don't see more stack trace information after applying patch in #27.

@jczuo: Perhaps try the attached patch instead (although Damien's patch did show a stack trace for me). In any case, although this is a more proper method I don't think it will result in a different result from what you had in #3, since that clearly showed the exception.

I am also now confused about the effect of patch #10. Above you seem to indicate different results at different times. To clarify, did you ever try patch #10 by itself (without #5 applied also)?

I think what you should do is the following:

1. Start with a completely fresh codebase/database/etc (as described above by Damien). Apply the attached patch (or Damien's in #27) and try to install Drupal.

2. Start again with a completely fresh codebase/database/etc. Apply both the attached patch and the patch from #10, and try to install Drupal.

Thanks!

Looking around the Internet a bit, I'm starting to get the feeling that this is due to http://eaccelerator.net/ticket/242. If so, I don't understand how the patch committed at #686596: Child before parent class definition order breaks some opcode cachers ever claimed to fix anything, and it is possible this is something Drupal cannot work around. But let's make sure before giving up.

Looking around there seem to be a number of issues related to this, but all were closed as not being Drupal's problem and not something Drupal can work around, although without a whole lot of investigation necessarily:

#615836: uncaught exception during install on mamp
#671444: D7 - PDO exception with cache_bootstrap

Let's use this issue to settle it once and for all. I'm retitling it appropriately.

@David_Rothstein: again, #3 likely shows the backtrace for a *different code path*. It is normal that this exception is thrown when settings.php is not configured yet. This exception will be caught and ignored when in drupal_get_path(), but it will not be ignored in other cases.

eaccelerator is a known pile of crap, but I would be very surprised if it was as broken as preventing exception from being caught. The most likely explanation is that the real exception that breaks things is triggered by a different code path. I want to know which one.

Ok, actually, the phpinfo() #6 shows:

PHP 5.2.2

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
    with eAccelerator v0.9.5.1, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
    with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend Technologies
    with Zend Optimizer v3.3.0, Copyright (c) 1998-2007, by Zend Technologies

eAccelerator v0.9.5.1 is definitely an affected version.

So this issue is either won't fix or we just need to add a new requirement check.

First shot at a requirements patch.

fresh code base + patch 27: after setting database:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'jczuo_61art.variable' doesn't exist: SELECT value FROM {variable} WHERE name = :name; Array ( [name] => install_task ) in install_verify_completed_task() (line 783 of /home/jczuo/domains/soqu.cn/public_html/drupal7/includes/install.core.inc).

reset code base, apply patch 29: after setting database:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'jczuo_61art.variable' doesn't exist: SELECT value FROM {variable} WHERE name = :name; Array ( [name] => install_task ) in install_verify_completed_task() (line 783 of /home/jczuo/domains/soqu.cn/public_html/drupal7/includes/install.core.inc).

then apply patch 10: after setting database:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'jczuo_61art.variable' doesn't exist: SELECT value FROM {variable} WHERE name = :name; Array ( [name] => install_task ) in install_verify_completed_task() (line 783 of /home/jczuo/domains/soqu.cn/public_html/drupal7/includes/install.core.inc).

I'm totally confused by the result: what ever patches I applied, the same result achieved; and not consistent with the result in #28.
Are these caused by eAccelerator? According to the patch in #33, Drupal 7 is not supposed to work if eAccelerator is enabled, is it true?
If yes, why Drupal 6 could be installed on the same host? Are there any approaches or work-arounds for me to install Drupal 7 successfully without removing eAccelerator (I'm not sure whether host vendor could remove it)

If it help, I could share my host account for debugging this issue.

Damien, great catch on the eAccelerator version. I agree it would be reasonable (and save lots of support requests) to print a requirement error if we have some reliable way to detect the version they are running, but it doesn't seem like we should prevent all versions of eAccelerator unless we know that the newer ones have problems too.

***

@jczuo, thanks for the additional testing. I have no idea how to explain the inconsistency in the results; it sounds like this could be just another aspect of the eAccelerator weirdness. The reason Drupal 6 worked is that Drupal 6 does not really use exceptions (which is what the eAccelerator bug you are hitting is related to), but Drupal 7 does.

If you (or anyone) needs to install Drupal with eAccelerator, I would suggest trying the following:

• Upgrade to the latest version of eAccelerator. Yours is old and out-of-date and known to experience these bugs with exceptions in PHP. It seems possible that the newer versions will work (and if they don't, it would be good to know).
• If you can't upgrade, you could try the workaround suggested in http://eaccelerator.net/ticket/242 (also see http://eaccelerator.net/wiki/Settings): Turn off the optimizer by setting eaccelerator.optimizer = "0" (probably in your php.ini file), clear the eAccelerator cache, and then restart Apache.

***

As an aside to Damien, maybe I'm just being dense but I still don't understand why the var_export() method in #3 wouldn't be good enough to debug this. I understand the point that there might be multiple code paths hitting that function, but I don't understand how there could be one that avoids the var_export(), and the results attached to #3 showed only one backtrace dump and one exception thrown, so i don't see how they couldn't have been related.

In any case, I guess it doesn't matter much now :)

I'm fine with blacklisting specific known-buggy versions of eAccelerator. I don't think we can get away with blacklisting eAccelerator entirely, though.

Is there a way to detect the version of eAccelerator that is running? If not, we may just have to show a non-fatal warning to all users of eAccelerator that some versions are known to suck, so you take your chances. (I think we're doing this for some older Postgres versions, aren't we?)

It is completely undocumented (confirming the general crappiness of eaccelerator) but this should work:

$info = eaccelerator_info();
if (version_compare($info['version'], '0.9.5.2') < 0) {
  // Cry wolf...
}

#33 is the only patch I'm ready to roll for eaccelerator.

So, any version (>0.9.5.2) of eAccelerator could work with Drupal 7?

My host vendor help me upgrade eAccelerator to v0.9.5.3, and now Drupal 7 could be installed successfully.
Thanks for all your help!

Buggy versions of eAccelerator don't get to be major Drupal bugs.

Reopening discussion.

On a MAC, with a recent version of MAMP with php 5.2.13, Apache 2.0.63 and MySQL 5.1.xx (can't find more) I'm able to install any version of Drupal 6. But for Drupal 7 I had to disable XCache (version 1.2.2) and Xdebug in my php.ini because it was throwing the same exception. And I verified eAccelerator was never enabled. I'm not whether I should open a new issue, but at least I searched and none mentions XCache. As this is the same exception it might be related so I post it here.

I had the same issue with installing Drupal 7 (LAMP). Installation only succeeded after disabling xdebug. eAccelerator is not installed.

Did you disable only xdebug or both xcache and xdebug ?

I didn't have xcache installed, so only disabled xdebug.

Both xdebug and xcache, but I think the problem is xdebug because I had an error beginning with something like "Trace ...", the kind of Xdebug output (because Xdebug traces the script).

Should this be a critical issue? It seems to me to be a bit of a potential embarrassment if D7 gets released and it won't even install in simple, relatively standard configurations that work fine with D6.

Changing the tag and description (to include xdebug), if only to ensure that someone more knowledgeable than me does give this due consideration.

Xdebug is a configuration issue and can be discussed on #947616: Warn people not to enable xdebug.show_exception_trace.

So if xdebug is handled on the other issue, that leaves us the buggy eAccelerator version, changing priority back and re-titling.

Thanks.

Too keep things rolling, this patch tests for a minimum eAccelerator version of 0.9.5.3 (confirmed to work in #41) instead of flatly refusing to support it.

patch in#52 not working for me

#52: 914742-52-eaccelerator-requirements.patch queued for re-testing.

Patch in #52 looks good to me. Re-rolled for 8.x and upgraded to RTBC.

Attachment...

This looks good but it would be nice to have some more test-feedback. According to #54 it might not be working?

Recently I think webchick has made a point of not committing patches like this (that target specific random pieces of software that someone might have on their computer)...

Is there a way to check for the actual bug in hook_requirements() instead? That would be more robust, if it's possible.

I'm going to mark this 'needs review' so we can discuss #58 and #59 more.

eAccelerator is pretty much dead these days, so my guess is that the number of users who would run into this problem these days is small enough that we shouldn't bother adding unnecessary code to core.

If anyone disagrees feel free to reopen the issue.