I recently noticed that Guests can not visit the same page twice in one session on my site.

The page shows up correctly on the first visit - upon reloading or visiting the page through another link, it will be blank. Changing the URL (even trivially, by adding "?test=1") will cause it to work - but again only once.

This only happens when I am not logged in. I assumed it was caused by a module at first, but I've disabled all non-required modules and the error still occurs.

The site is at http://arancaytar.ermarian.net/ .

Please tell me if you get the error as well; it may be on my end.

CommentFileSizeAuthor
#15 user_cache.patch517 byteskilles@www.drop.org
#11 111697_0.patch532 bytesWesley Tanaka
#10 111697.patch500 bytesWesley Tanaka

Comments

cburschka’s picture

cburschka
they
commented

I now know this doesn't only happen on my computer only. This only occurs on one of my sites, but on that site it always occurs, regardless of what modules are enabled. Does anyone have any ideas for why this could happen?

cburschka’s picture

cburschka
they
commented
Title: Blank page on reload » Undefined property: stdClass::$cache in cache.inc on line 37

I'm changing this title based on what I've found out now.

Accessing my site through lynx from another computer (I have no idea why) shows an error message instead of the standard blank response.

The error message is this:

 Notice: Undefined property: stdClass::$cache in
   /drupal-install-path/includes/cache.inc on line 37
   }vF9ix...

The error is followed by a page of gibberish that I've cut short here.

SubWolf’s picture

SubWolf commented

While I haven't experienced this problem myself, I'm now hearing from clients and friends that it is happening to them, and I have no solution to offer so far, the code at first glance looks fine.

Help!

cburschka’s picture

cburschka
they
commented

I've worked around this by disabling page caching.

I don't know what exactly was the problem, but I've noticed that the error notice still appears occasionally at the top of the page, and it might be this notice that has "broken" the caching system by interfering with the HTTP headers (speculation).

Since it is a notice, it can be removed by disabling the "E_ALL" error mode. Whether this solves the original problem - ie that an enabled page cache causes blank pages - I haven't yet tried out.

Anonymous’s picture

Anonymous (not verified) commented

I am curious to your PHP version, OS Information and please mark the correct Drupal version.

Line 37 of cache.inc for 6.x-dev: 

      if ($user->cache > $cache->created) {
        // This cache data is too old and thus not valid for us, ignore it.
        return 0;
      }
cburschka’s picture

cburschka
they
commented
Status: Active » Closed (fixed)

Unfortunately (or fortunately?), I can't reproduce it anymore. Viewing as guest or as a logged-in user, it works without blank pages or error notices. Here are three things I changed since then:

1.) Upgraded PHP to version 5.2.1 (from 5.1.4)

2.) Downgraded Drupal from 6.x-dev to 5.1 (I know I shouldn't have used the HEAD anyway, but when it's not currently going through the early phases of a new major release, it's not such a problem)

3.) Removed php error_reporting(E_ALL); from my settings page (should also have done this some time ago as I was done debugging).

Any of these could have fixed it (I'm tending to the third one, really, since this was an error notice and won't be displayed when E_ALL is off.

So I'm closing this for now... the only issue that really remains is the often-requested E_ALL error-free compliance.

Wesley Tanaka’s picture

Wesley Tanaka commented
Version: 6.x-dev » 5.1

I'm getting this in IE. It happened to be the first time I was looking at a particular "domain" on my local computer with that IE.

Wesley Tanaka’s picture

Wesley Tanaka commented

The $user object at the point where I get the error:

stdClass Object ( [uid] => 0 [hostname] => 127.0.0.1 [roles] => Array ( [1] => anonymous user ) [session] => )

Note that there is, indeed, no cache field.

Wesley Tanaka’s picture

Wesley Tanaka commented

Some "printf debugging" reveals that the $user object is coming from here (in session.inc)

  if (!isset($_COOKIE[session_name()])) {
   echo '<h1>Hi</h1>';
    $user = drupal_anonymous_user();
    return '';
  }

drupal_anonymous_user does in fact, not set a cache field. I'm not sure if the solution is to change drupal_anonymous_user() or to change line 37 of cache.inc

Lemme go figure out what $user->cache means...

Wesley Tanaka’s picture

Wesley Tanaka commented
Title: Undefined property: stdClass::$cache in cache.inc on line 37 » Notice: Undefined property: stdClass::$cache in cache.inc on line 37
Component: base system » user system
Category: support » bug
Priority: Normal » Minor
Status: Closed (fixed) » Needs review
StatusFileSize
new 111697.patch500 bytes

Okay, this seems to affect anonymous users that do not have an entry in the sessions table. The output created is a notice, so the obvious workaround is to turn off notice reporting. $user->cache is used to simulate a cache flush without actually flushing the cache -- if a piece of cached data is older than the $user->cache timestamp, it's ignored in cache_get (the check on line 37).

There are two ways to fix this:

1. Treat a non-existent $user->cache to mean $user->cache == 0
2. Set $user->cache to 0 in drupal_anonymous_user

Attached to this comment is a patch for approach #2

Wesley Tanaka’s picture

Wesley Tanaka commented
StatusFileSize
new 111697_0.patch532 bytes

This patch implements approach #1

Wesley Tanaka’s picture

Wesley Tanaka commented

A workaround for those hitting this in development is to do an action in your browser that would cause you to acquire a session (visiting the login page?), and then DELETE FROM {cache_page} to get rid of any pages with cached notices.

joemoraca’s picture

joemoraca commented

I applied the patch in comment #11 and it seemed applied fine but I didn't have the problem before the patch and don't have it after the patch.

owen barton’s picture

owen barton commented

Subscribing.

http://drupal.org/node/123717 has been marked as a dupe

killes@www.drop.org’s picture

killes@www.drop.org commented
Version: 5.1 » 6.x-dev
Status: Needs review » Reviewed & tested by the community
StatusFileSize
new user_cache.patch517 bytes

Moving this to HEAD so it can first be applied there. Should be backported to D5. I am not sure if the attached patch is the right one. Attached is an alternative patch which sets $user->cache = 0 for anon users. One of them is good to go.

Wesley Tanaka’s picture

Wesley Tanaka commented

Maybe you didn't see the patch in #10?

dries’s picture

dries commented
Status: Reviewed & tested by the community » Fixed

I've committed this to CVS HEAD and DRUPAL-5. Yay!

hawkdrupal’s picture

hawkdrupal commented
Title: Notice: Undefined property: stdClass::$cache in cache.inc on line 37 » Undefined property: stdClass::$cache in /srv/www/htdocs/d/includes/session.inc on line 77
Version: 6.x-dev » 5.1
Component: user system » base system
Priority: Minor » Critical
Status: Fixed » Active

I have this problem repeatedly. The error says the problem is in session.inc. Apparently, the cache isn't being set for anonymous users.

My problem is documented here:
http://drupal.org/node/132740

I applied the patches provides in this thread, but they didn't help:
http://drupal.org/node/111697

At this point, Drupal 5.1 is unusuable.

Wesley Tanaka’s picture

Wesley Tanaka commented
Title: Undefined property: stdClass::$cache in /srv/www/htdocs/d/includes/session.inc on line 77 » Notice: Undefined property: stdClass::$cache in cache.inc on line 37
Priority: Critical » Minor
Status: Active » Fixed

Unfortunately most open source bug tracking processes have a somewhat misleading definition of the "fixed" status (Drupal's included). It means "a fix has gone into source control somewhere" as opposed to "you should be able to get a fixed version of the product now". In this particular case, the fix should be available whenever the next release after 5.1 is released (which seems to be taking a long time).

That being said, if your notice is coming from a different file and a different line number, that means that it's a different issue, which you should open a different (new) bug report for.

Tresler’s picture

Tresler commented

Said fix is in CVS. as Dries says here http://drupal.org/node/111697#comment-219111

You want to check out a new copy of DRUPAL-5 from CVS instructions are in handbook here: http://drupal.org/handbook/cvs

Make sure you get the right version - not HEAD. Cheers!

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)