"Call to undefined function lock_acquire", locale module

It is included by bootstrap, although maybe it's later than needed?

    case DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE:
      // Initialize configuration variables, using values from settings.php if available.
      $conf = variable_init(isset($conf) ? $conf : array());
      $cache_mode = variable_get('cache', CACHE_DISABLED);
      // Get the page from the cache.
      $cache = $cache_mode == CACHE_DISABLED ? '' : page_get_cache();
      // If the skipping of the bootstrap hooks is not enforced, call hook_boot.
      if (!$cache || $cache_mode != CACHE_AGGRESSIVE) {
        // Load module handling.
        require_once './includes/module.inc';
        bootstrap_invoke_all('boot');
      }
      // If there is a cached page, display it.
      if ($cache) {
        drupal_page_cache_header($cache);
        // If the skipping of the bootstrap hooks is not enforced, call hook_exit.
        if ($cache_mode != CACHE_AGGRESSIVE) {
          bootstrap_invoke_all('exit');
        }
        // We are done.
        exit;
      }
      // Prepare for non-cached page workflow.
      require_once variable_get('lock_inc', './includes/lock.inc');
      lock_init();
      drupal_page_header();
      break;

Don't if this can be of any help but I had the same error and it's gone away my cleaning-up APC cache. I'll see if this appears later on.

If you are able to reproduce this error consistently, could you please try to find out how locale.module is included (a debug_backtrace() directly in locale.module will do).

Because as far as I know:

- t() will only call locale() if that function is defined (ie. if locale.module has been loaded)
- the locale module can only be loaded in DRUPAL_BOOTSTRAP_FULL, ie. after lock.inc has been loaded in DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE

The only thing I can think of that could happen is that DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE loads a cached page, a module implements hook_boot() and has a drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) directive in it, the other bootstrap phases are executing, but not the loading of lock.inc at the bottom of DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE.

Drupal 7 is not affected by the potential bug I described above. Let's assign to the 6.x branch.

I got this only on one of my 10 multi-site installations. How can this be fixed? I cannot access that site at the moment.

I had this error, but with includes/menu.inc. I just restored menu.inc from the backup taken just before I did the upgrade.

I don't think that's a right way to go, then you are probably using the menu.inc file from Drupal 6.15.

I got the same error. Now my site is totaly crashed..

Thanks a lot... Subscribing

Did you run update.php?

Anyone experiencing this issue:

- Did you make sure lock.inc was copied properly to the webroot from the release (eg. if you pull files from CVS to a version control system you use)
- Did you run update.php?
- If you or your host is running any code cache like APC, have you reset the cache?

I'm running 6.16 on some sites using locale module including localize.drupal.org and did not see this issue.

I had the issue as well, but had only uploaded all the modules and updated & cleared cache.
But after uploading the new includes directory, including the lock.inc as Gábor indicates, it's solved. :-)
Thanks Gábor!

Well the error is gone, and my site is functioning properly, so for now, its a solution

I've added this to the front page post:

A new includes/lock.inc file is included with this release to support the locking subsystem. This also involved some database changes. To make sure your site continues to function right, running update.php is extremely important. If you deploy using a version control system, make sure to commit lock.inc to your production codebase. Finally, if you run a bytecode cache such as APC, reset the cache to let it reread the changed files.

I'm stuck with this problem, how can I tell if any of my modules uses APC cache and if so, how can I reset the cache?
I'm running multisite and one of my sites is giving me this error.

To be more specific, site is crashing down every once in a while when logged in. Only way to make it work again is to refresh update.php -page. Any ideas how to proceed? Site is production site so I have to get it working asap!

Without further debugging, we'll not see an "official patch" though. Since this error seems to have happening to a small amount of people, and we could not reproduce it so far, it is no trivial to provide a fix.

Thank you for your reply cfab. I'm still going to search for the problem's source, because this is multisite install and I wouldn't want to interfere the core if not absolutely neccessary.

Can any of you to trace the problem for example to older version of views- or og-modules, because I cant find any other differences between our multisite-sites?

Versions at the broken site:
- Views 6.x.2.3
- Organic groups 6.x-1.1
- OG Menu 6.x-1.3
- OG Forum 6.x-1.4
These modules cannot be updated to newer versions, but it would be great if anyone knows where to start looking!

There used to be some modules, which used t() on the main PHP code level. That is outside functions. So that code run before any of Drupal's bootstrap could, and therefore caused problems. It could cause these problems currently. Look for things like: define('some_constant', t('some string')); in your modules and theme template.php or any other use of t() and friends outside of functions.

Having this problem too, on one site only of a multi-site installation.

Please see a stack trace attached, taken inside locale.module:354, just before the error.

UPDATE: btw, have anybody noticed a weirdness when downloading the file? is it another drupal's shortcoming? anyway, just escape a hash-sign with %23, that is: http://drupal.org/files/issues/20100305-drupal-6.16-%23732064-stack_trac...

@esteewhy - there is a filename problem with your stack trace.

There are now quite a few folks who are having this problem (according to Google)

@str1 - We're using APC & have cleared cache using the following from the command line:
# php -r "apc_clear_cache();"

and are still having problems.

We've also run update.php & cleared our cache.

We're using this on a pretty i18n intensive site (BIDI trilingual site) and so not sure which module might be casing the problem.

The lock.inc file is in the includes directory. Not sure where to go from here.

@mgifford

Are You using OG ?

@esteewhy - not on this site.

I was able to resolve it momentarily by hacking in an include on line 355 of modules/locale/locale.module:
include_once('/my_path_to_the_file/includes/lock.inc');

It's getting us working again. But looks like there's going to need to be another release of Drupal soon to deal with this.

I'm also not sure if my hack doesn't also introduce problems. It just fixes this one.

After the upgrade from D6.15 to D6.16 I noticed the following error when running drush commands

PHP Fatal error: Call to undefined function lock_acquire() in /var/www/drupal/modules/locale/locale.module on line 357

After disabling locale.module I don't see the error anymore and the site apparently works fine for regular users.
However I am still hitting WSOD as user 1 in the following circumstances:
- when trying to run update.php as user 1 (I assume my db is not updated yet...)
- when saving any form in admin UI as user 1

Moving require_once variable_get('lock_inc', './includes/lock.inc'); to the very beginning of bootstrap.inc does not help.
Anything else I could try? Thank you.

[edit]
weird... after rolling back to D6.15 I still get the admin pages WSOD on Opera (I did clear both server and browser caches),
but I don't see any WSOD problem on Firefox or Chrome.

subscribing

I ran into this problem when I ran update.php to D6.16. I used the back button, then to reports and the D6 update appeared successful and the site was functioning. Now I've seen this issue two more times, both while attempting some admin function, the last time I was disabling a module. My changes were successful, but the fatal error is worrisome.

Also experiencing the problem, although it took awhile for me to see it as it appears sporadically. When I could see it, it was on a node view like /fr/node/12345. Removing the /fr allow the page to load normally in the default language (en).

subscribing

Thanks mgifford for the info

I also hardcoded this into Drupal core's locale.module after declaration of "function locale" on the row 330. So for all who are in trouble with this, temporary solution is to add this include into your path_to_your_drupal/modules/locale/locale.module

include_once('/<path_to_your_drupal>/includes/lock.inc');

If the the problem is not solved until the next Drupal update, can this same kind of include line be added to core module by developers, so that this modifiaction won't be lost on next update and this same problem would not rise up again?

And please be aware, this is tested only in our environment, not sure if has any side effects

@esteewhy: looking at your dump, it does seem like the late page cache boostrap phase was invoked, so lock.inc should have been included. Your dump even shows hook boots being called, which is in that phase. The dump shows that the lock_acquire failure was due to a menu item being loaded and localized in og_init, if I'm seeing right, so I'm wondering how could that not see the lock API.

Are you sure you have the latest bootstrap.inc file from Drupal 6.16? The numbers are not adding up for me. Your dump has a bootstrap_invoke_all('boot') call on line 1050, but my copy of Drupal 6.16's bootsrap.inc do not have such code on that line.

@Gábor

Regarding bootstrap.inc version
I've downloaded 6.16 anew, `diff` shows that the files are identical in both cases.
Here's what `head` shows:

<?php
// $Id: bootstrap.inc,v 1.206.2.14 2010/02/01 16:49:14 goba Exp $

/**
 * @file
 * Functions that need to be loaded on every Drupal request.
 */

/**
 * Indicates that the item should never be removed unless explicitly told to

Maybe, I should make clear what my upgrade process looks like to make sure all files are up to date? Here is how it typically goes:

1. Back up ./sites
2. Unlink drupal from drupal-6.15
3. Roll out drupal-6.16
4. Remove stock drupal-6.16/sites
5. Restore my custom ./sites
6. link drupal to drupal-6.16

The weakest point here, I suspect, is something in the custom ./sites. Is there anything beyond settings.php that could cause a problem? On the other hand, settings.php differs from a stock one in only $db_url content.

At first, I was tempted to blame the OG. But since mgifford doesn't use it, and also suddenly one my another site, which doesn't use OG, fell prey with a similar symptoms, I'm not so sure about OG's role..

Let's dig further..

@esteewhy: in your case, it's the trace module doing something silly: calling drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) directly into trace.module.

It's exactly what I described in #5.

@Damien

That trace.module well may be the cause: I've removed mgifford's and str1's fix, turned trace.module off on both sites, and WSOD went away.
Thank You, Damien!

Anybody else, having this problem, uses trace.module ?

Subscribing.
Intermittent WSOD - running 5.2.11.

I have no trace.module on my system at all, so I'ts not the source of our problem.

Same error here with a 6.16 and OG active. Currently using the evil include hack as workaround...

If you have a Trace module installed, maybe this could help.

So this seems to be a pretty critical issue that's going to hit a lot of sites who upgrade.

Is there any way to resolve the problem with the new lock file & put out a new release? Seems like this might be important with or without a security update.

With both i18n & og faltering with the upgrade, either those modules need to upgrade, or there should be fix in core.

@mgifford: as soon as we could figure out what exactly is causing these, we could decide whether contrib modules or core needs updates. So far we are still in debugging mode and looking at every piece of debugging data sent in by people. I could not reproduce this on any of my sites (some running OG with Drupal 6.16), so I could not gather more info myself so far unfortunately.

Let me know what you need and I can work to reproduce it for you again.

Lists of modules (and versions) installed is fairly easy. Suggestions on sending you other debug info would be appreciated. I can run this and get back to you.

Odd that it's hitting only some systems. Wonder if it's a system environment issue?

@cfab: calling t() and friends too early before the localization system is initialized is a problem in itself; if we mask that by working around its most visible result, that is just sidestepping the problem instead of solving it.

@mgifford: you could feed us some valuable data by doing this modification. Look at this code:

    if (variable_get('locale_cache_strings', 1) == 1) {
      if ($cache = cache_get('locale:'. $langcode, 'cache')) {
        $locale_t[$langcode] = $cache->data;
      }
      elseif (lock_acquire('locale_cache_' . $langcode)) {

And change it to something like:

    if (variable_get('locale_cache_strings', 1) == 1) {
      if (!function_exists('lock_acquire')) {
        var_dump(debug_backtrace());
        exit;
      }
      if ($cache = cache_get('locale:'. $langcode, 'cache')) {
        $locale_t[$langcode] = $cache->data;
      }
      elseif (lock_acquire('locale_cache_' . $langcode)) {

This will make your code die at this point, but it would die anyway later when it finds out lock_acquire() is not there. Best to experiment on a testing environment. Anyway, the above could tell us where is it called from and we could track it back to why its called that early.

I am experiencing this on a site that does not use OG or Trace.

I'm getting this on a site using og_user_roles to be more specific. During the hook_init phase maybe? of hook_boot (if such a hook)

Call Stack
#	Time	Memory	Function	Location
1	0.0001	54616	{main}( )	../index.php:0
2	0.0005	70348	drupal_bootstrap( )	../index.php:16
3	0.0869	139552	_drupal_bootstrap( )	../bootstrap.inc:989
4	0.0943	351196	bootstrap_invoke_all( )	../bootstrap.inc:1050
5	0.0988	532164	module_invoke( )	../bootstrap.inc:591
6	0.0989	532388	call_user_func_array ( )	../module.inc:462
7	0.0989	532564	og_user_roles_boot( )	../module.inc:0
8	0.0989	532672	og_user_roles_all_roles( )	../og_user_roles.module:1288
9	0.0989	532776	drupal_bootstrap( )	../og_user_roles.module:2160
10	0.1039	542728	_drupal_bootstrap( )	../bootstrap.inc:989
11	0.1045	677484	_drupal_bootstrap_full( )	../bootstrap.inc:1080
12	0.1569	1903928	module_invoke_all( )	../common.inc:2622
13	0.1591	1911296	call_user_func_array ( )	../module.inc:483
14	0.1592	1911296	lightbox2_init( )	../module.inc:0
15	0.1592	1911296	lightbox2_add_files( )	../lightbox2.module:303
16	0.1599	1915792	t( )	../lightbox2.module:663
17	0.1600	1916120	locale( )	../common.inc:917

So maybe lock.inc needs to be included earlier.

I tried to replicate the problem but couldn't.

I do wonder if it might be tied to lightbox2.. We had to disable it yesterday due to some other issues.

I'll definitely provide a a dump if we find the problem again.

IMO lightbox isn't the culprit in #46

7	0.0989	532564	og_user_roles_boot( )	../module.inc:0
8	0.0989	532672	og_user_roles_all_roles( )	../og_user_roles.module:1288
9	0.0989	532776	drupal_bootstrap( )	../og_user_roles.module:2160

in the middle of a bootstrap another bootstrap is unchained by og_user_roles_boot
$phases is static in bootstrap, this would make it jump bypassing lock.inc, which is in DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE but after bootstrap_invoke_all('boot');

subscribing

Although expected due to the nature of the bug : drush is wreched (most commands cannot be completed). Cache cleared and all. Because this wsod described above happens sporadically, drush made it absolutely clear that this is a consistent bug .

So it seems that I was right back in #5.

We need to make the loading of the lock implementation its own phase.

Applied patch ,things got worst. Reverting back to core.

I did not experience this problem on my sites BUT I noticed how I can create it. Using Secure Site tends to produce this error however never for UID1 and for any other users only sometimes. Don't know if this information helps but I thought it would be a good idea to share it.

Issue at Secure Site: #736110: Blank screen of death with Drupal 6.16 using securesite

Solution on comment #31 fixed our problem. we have to somehow warn people upgrading to 6.16

Trick is that it isn't consistent. I couldn't repeat it two days later.

If you've currently got this problem, please look at #44 to be able to provide reports that allow the issues to be better understood.

Patch realizing solution on comment #31, credit to str1

I think the best way to reproduce this every time , is to use drush. Before applying the #31 , I was getting this every time I was trying to run most drush commands. I also use Securesite by the way.

Hi I had the same issue with one of my sites on a multisite install. Most of the other sites were unaffected.
The site, did have securesite installed.
To get into the admin:
1 I had to turn $update_free_access = TRUE; in settings php.
2 I specified the link to take me to my default lang en/admin?destination=admin
3 I was able to login, disable securesite, clear the cache and things seem to be working.

Hope this helps

Everyone, please try #51, it seems to be the correct fix for this issue.

If #51 doesn't work for you, please use the technique described in #44 to give us some useful information.

subscribing.

I have this issue on a 'virtual site' setup (not multisite) that has multiple languages. Switching languages on the fly causes a whitescreen.

I've never applied a patch before, except by manual editing, so i'll look now into how to 'patch', and report back if i see further errors.

Unfortunately the patch does not work for me. Changing languages or even trying to clear my cache gives me the lock_acquire error.

Can you insert the code here http://drupal.org/node/732064#comment-2694334

This might help us determine what the problem is.

Also what patch did you apply where? Did you clear the cache?

I added the patch from #51

I can't clear the cache. Trying to clear the cache gives me the same error.

I'll add the code you mention and let you know

Whn I try to clear the cache, I get the following
Call to undefined function lock_acquire() in /home1/helmarca/public_html/dance-ottawa/includes/menu.inc on line 1693

I dont use secure site, but I am using multiligual. I have tried to disable multilingual, but im still getting errors, mostly acquire_lock errors in menu.inc

subscribing.

I have the same issue.

Originally I have multi-site setup (2 sites, 1 of which are multilingual, with Secure Site enabled for both site).

And then I updated to D-6.16. Both site are fine.

And then I add extra multilingual site to the multi-site, without Secure Site enabled. Only the new site got this problem.

Hope this information helps to find the root cause.

@dpatte & @robonoob please look at applying the PHP suggested in comment #44 above.

This is really the only way we're going to be able to track down what's wrong and how to fix it for the next release.

Or for that matter delivering a patch that fixes it for those who have already upgraded.

where is this code to be applied, as I have crashes in various modules including locale and menu - to start.

Unfortunately, things seem to have gone from worse to worser :)

Anyway - my site is barely working at this point so editing it to track down the bug is too risky - but i did discover that in my error log, immediately before this started happening, presumably while upgrading to the latest core, i got the following errors:

[04-Mar-2010 18:36:48] PHP Warning: Unexpected character in input: ''' (ASCII=39) state=1 in /home1/helmarca/public_html/dance-ottawa/modules/system/system.module on line 188
[04-Mar-2010 18:36:48] PHP Parse error: syntax error, unexpected $end, expecting ']' in /home1/helmarca/public_html/dance-ottawa/modules/system/system.module on line 188
[04-Mar-2010 18:37:43] PHP Fatal error: Call to undefined function lock_acquire() in /home1/helmarca/public_html/dance-ottawa/modules/locale/locale.module on line 357
[04-Mar-2010 18:38:12] PHP Fatal error: Call to undefined function lock_acquire() in /home1/helmarca/public_html/dance-ottawa/modules/locale/locale.module on line 357

My current state, after trying to track this down, now gives anyone except the admin a 'permission denied' on all my pages :(

Yes, it should be in modules/locale/locale.module

Just search for locale_cache_strings.

Thanks @mgifford,

I did not apply the patch. The new multilingual site is critical only for me to learn drupal better. It is ok for me to leave it there.

Here are some more information about the New site.
. English is not the default language.
. Caching mode:none
. no node content was created.
. no user other than super user was created.

And here is a list of scenario which occurs consistently. (This is how I re-enable my site without any patch)
1. The English version can be accessed. Site in other languages fails.
2. The bug was gone once I logged in super user (ID=1) and I can change into different languages without error.
3. Log out and only English remains functional (if only English part was viewed during login)
4. Log out and the whole site remains functional (if all languages were selected during login)

At this point, the bug seems gone. And it comes back again after a certain period. (I suspect this illusion may caused by the image in some cache)

5. So I clear all cache via Adminmenu in one language Z, and then logout, only English and the site in language Z is working.
6. I logged in and clear all cache in English, then logout, leading to a site only functional in English.

The above scenario are the same for another multilingual site setup in the same multi-site environment which was based on D6-6.15. The bug affects all sites in multi-site environment.

I did not try whether the bug will leave if I change the locale module weight, so to make it run in earlier, maybe?

I just read the change log of D6.16 and found that 4 fixes are related to locale and only the fix for the bug (http://drupal.org/node/251792) are related to locale cache. And the patch is "Implement a locking framework for long operations"......

I am not good at drupal core.... But hope this may be a hint for hunting the bug.

And I am adding code mentioned in #44.... more on this later.
Code fragment in #44 was applied. Please refer to attached file in #73 for the screen output.

Hope this helps.

@#73 it seems the same thing to me: a contrib module (securesite) making a bootstrap in hook_boot/init

is this happening due to a lack of documentation, or what?
is it required more guidance regarding what is allowed on early stage hooks?
or contributors are just undisciplined?

I have had previous issues with 3rd party modules doing too much in hook_boot/init
and had to sorted out compatibility issues to support offender modules

now the core itself has been pointed out as potential offender (not being truth) and has no way to point out the actual offender module (unless requesting users to hack it to check dumps),
and it can't keep the site working with such an ongoing misbehavior

IMO it seems a good time to prioritize contributors' instruction regarding what is NOT allowed (by contract) to be performed on early stages (i.e. boot/init)

@arhak,

Do you mean that you sure the root cause is in the secure site, instead of the locale module ? (Of course, I am really not sure on this. I just want to see if I can help finding out the bug by providing more evidence)

If so, would you please tell me on which line in which file I have to change?

Or are you suggesting that I should disable and uninstall and remove the Secure Site module?

And it seems strange to me, as my new multilingual site do NOT have secure site enabled. I am confused. Do you mean that the hook_boot/init in some contributed will be fired even they are not enabled (I suspect not) ? If it is right, I'll need to clean up the modules directory under sites/all in such a way that, not only to disable/uninstall unused modules, but also to remove them.

Secure Site is not the cause as we had this problem on sites without Secure Site, #56 fixed our problem.

I've resolved my permission denied error - which was my own fault, not a fault of this upgrade.

Appling patch from #51 didn't work. Same error as before applying the patch.

This fixed it for me.

@Josh Waihi - that looks like a reasonable change - since the default implmentation uses the database, we certainly can't move it earlier than there.

Do we need to move it earlier in Drupal 7 also?

I applied the patch from #51 but found I was still getting errors from menu.inc so I have also added
require_once variable_get('lock_inc', './includes/lock.inc');
jst before the lock_acquire call in menu.inc

My errors have disappeared now without caching on.

But I've run into a new problem when I then enable caching in performance.

headers already sent in bootstrap.inc 701
when trying to send headers in common.inc line 148

If its of interest - i18n & locale, that i was using before, are no longer enabled - i can wait until caching is working before I try those.

I'm unsure (I haven't checked). Most likely, core is fine as is, but I have a feeling contrib will require locale shortly after the database layer has been bootstrapped. So IMO its a good idea to include the lock layer just after the database.

Applied patch #51 and get this error

Hunk #1 succeeded at 83 (offset 1 line).
Hunk #2 FAILED at 1065.

My site still shows

Fatal error: Call to undefined function lock_acquire() in /path_to_my_site/modules/locale/locale.module on line 358

Applied #44 and I get this

array(9) { [0]=> array(4) { ["file"]=> string(57) "/home6/curefans/public_html/listadark/includes/common.inc" ["line"]=> int(907) ["function"]=> string(6) "locale" ["args"]=> array(2) { [0]=> &string(11) "Your rating" [1]=> &string(2) "es" } } [1]=> array(4) { ["file"]=> string(70) "/home6/curefans/public_html/listadark/modules/fivestar/fivestar.module" ["line"]=> int(1505) ["function"]=> string(1) "t" ["args"]=> array(1) { [0]=> &string(11) "Your rating" } } [2]=> array(4) { ["file"]=> string(70) "/home6/curefans/public_html/listadark/modules/fivestar/fivestar.module" ["line"]=> int(77) ["function"]=> string(15) "fivestar_add_js" ["args"]=> array(0) { } } [3]=> array(2) { ["function"]=> string(13) "fivestar_init" ["args"]=> array(0) { } } [4]=> array(4) { ["file"]=> string(57) "/home6/curefans/public_html/listadark/includes/module.inc" ["line"]=> int(483) ["function"]=> string(20) "call_user_func_array" ["args"]=> array(2) { [0]=> &string(13) "fivestar_init" [1]=> &array(0) { } } } [5]=> array(4) { ["file"]=> string(57) "/home6/curefans/public_html/listadark/includes/common.inc" ["line"]=> int(2612) ["function"]=> string(17) "module_invoke_all" ["args"]=> array(1) { [0]=> &string(4) "init" } } [6]=> array(4) { ["file"]=> string(60) "/home6/curefans/public_html/listadark/includes/bootstrap.inc" ["line"]=> int(1084) ["function"]=> string(22) "_drupal_bootstrap_full" ["args"]=> array(0) { } } [7]=> array(4) { ["file"]=> string(60) "/home6/curefans/public_html/listadark/includes/bootstrap.inc" ["line"]=> int(995) ["function"]=> string(17) "_drupal_bootstrap" ["args"]=> array(1) { [0]=> ∫(9) } } [8]=> array(4) { ["file"]=> string(47) "/home6/curefans/public_html/listadark/index.php" ["line"]=> int(16) ["function"]=> string(16) "drupal_bootstrap" ["args"]=> array(1) { [0]=> ∫(9) } } }

"Solved" temporary this by commenting lines 358 to 368 from the file locale.module in the folder modules/locale

Comented from this line

elseif (lock_acquire('locale_cache_' . $langcode)) {

to this one

}

I also commented the patch suggested in #31 because it was giving a lot of warnings.

This is indeed a head splitter problem.

I've updated numerous sites from 6.15 to 6.16 and got bite only tonight by this locking bug on a production site.

I do have an almost complete backup of the production site without secure site. So when I did not notice any issue with the test site, I proceeded to upgrade the production site, and was bit hard...

I've read all post here and yeah! Secure site was the problem! Well my problem, cause looks like the locking is affecting some other modules.

I have i18n on one site and both test and prod updated correctly.

But for the production site that I have, there are not i18n, no og, no trace. But yes, another language is defined as default. Well, all the sites that have D6.16 have as well another language enabled by default.

It is a cache problem - to log in to clear the cache, just comment out the following, save, log in, clear cache, the uncomment;

/*
elseif (lock_acquire('locale_cache_' . $langcode)) {
// Refresh database stored cache of translations for given language.
// We only store short strings used in current version, to improve
// performance and consume less memory.
$result = db_query("SELECT s.source, t.translation, t.language FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = '%s' WHERE s.textgroup = 'default' AND s.version = '%s' AND LENGTH(s.source) < 75", $langcode, VERSION);
while ($data = db_fetch_object($result)) {
$locale_t[$langcode][$data->source] = (empty($data->translation) ? TRUE : $data->translation);
}
cache_set('locale:'. $langcode, $locale_t[$langcode]);
lock_release('locale_cache_' . $langcode);
}*/

Looks like that cache should be cleared by the update function from 6.15 to 6.16.

Patch needs a reroll.

subscribing

re-roll for D6 with more code comments

here's a D7 version - since likely we shoudl make the same change.

Like the addition of inline docs. Patch looks pretty clean for D7. Totally trivial, but the D6 probably should have space before the comments.

I don't have an environment where I can test and replicate either of these patches at the moment however. Only because I haven't been able to replicate the problem I first reported.

We recently had this issue on one of our multilingual drupal sites running i18n. We managed to get the site working again by applying the patch on comment #92

With the site up we cleared the cache and then reverted the patch, the site was working again properly and no errors were being reported.

Did the same as arvinsingla in #95 but once I reverted bootstrap.inc, the error was showing again.

Applying the #92 patch worked for us.

Thx!

@mgifford - I don't see where you expect there to be more space. RTBC?

Sorry, no extra spaces in the patches. Not sure where I picked those up.

I installed the patch and then reinstalled it D7 here - http://drupal7.dev.openconcept.ca - and it worked fine.

I don't have an install that produces the problem, but I do think this could be RTBC. I'd like to get a confirmation from someone had the initial lock problem first.

@jpoesen did you just apply the patch? Did you have the lock_acquire problem?

I was able to recreate the misbehaviour on my local install. Applying the patch seems to be the cure as I am unable to recreate the problem now.

edit: I used the patch from #92.

Should we be using only the patch from #92? Does this replace the patch from #51, or should they both be used?

following.

@mgifford: we used drush 6.x-3.x-rc2 to upgrade a D6.14 to D6.16, encountered the lock_acquire problem and fixed it by applying the #92 patch.

patch attached to comment #92 fixed the prob for me too.

Instead of patch #51, I have now tried patch #92 instead, and I'm happy to say it works. I was able to restore menu.inc to its original 6.16 condition, and also was able to re-enable caching.

Two things I haven't tried to re-enable yet are i18n & locale, which where working before the upgrade, but I'll try them again soon and report back.

It seems to work great guys! Thanks!

update: 2010-5-19 Re-enabaled locale and i18n and i can report that they too seem to work fine again. Thanks everyone.

following.

The change to D7 is neither required (see #6) nor desirable (we don't need to load more code in the cached code flow.

#92 looks like a decent solution for D6. The alternative solution, which doesn't require to load more code in the cached code flow is to fix my patch in #51. The only thing missing there is to add DRUPAL_BOOTSTRAP_LOCK to the list of phases in _drupal_bootstrap() [oups...].

#88 worked for me

(using D6.16, securesite and default language Dutch)

#92 This patch worked for my multilingual site as well.

Thanks,

JanPieter

Thanks for all the great feedback on the Drupal 6 patch in #92, committed that. Looks like we need something else for D7, so moving there.

Lets open another issue for 7.x as this 6.x bug affected many people and it is not even clear that it was fixed.

Hi, Can you explain exactly how and from what directory should I to apply the patch in #92?

Thank you

OK!... I'm sorry... Procedure to apply the patch if you don't know how to do that...

(1)
Get the patch in the 'includes' directory ([root@location]# wget http://drupal.org/files/issues/732064-load-lock-api-early-92-D6.patch)

(2)
[root@location]# patch < 732064-load-lock-api-early-92-D6.patch
patching file bootstrap.inc
[root@location]#

I've a multilanguage site, thus I've repeat the step in my others location.

Regards!

Does anyone know what the status of this is in D6.17?
Does it need a patch or is this issue resolved in D6.17?

This is fixed.

its fixed in 6.17

After replacing includes folder I got the solution.

Anyone out there please help. I have users who continue to get this error:

/locale.module on line 357

It only appears when users access the site with a browser locale that is none us.