prefs bug possibly

I have a few users who repeatedly lose the ability to view t

Tue, 02 Aug 2011 14:49:50 +0000

I have a few users who repeatedly lose the ability to view their mail. Instead they get a 500 internal server error after logging in. We log in using IMAP and here is a horde log in debug mode.... I can't figure it out. This is a log of a user logging in.. somethings have been replaced but it's all there.. this is from our live site After deleting the user's database entries in horde_prefs, they can use the application for a while.. maybe a week.

also this time I deleted only the pref with pref_name= "last

Tue, 02 Aug 2011 14:55:32 +0000

also this time I deleted only the pref with pref_name= "last_logintasks" and the user could log in again.. the pref had this value in it a:2:{s:5:"horde";i:1312295560;s:3:"imp";i:1312076139;}

these issues I will mention in case they are related to this

Tue, 02 Aug 2011 15:18:22 +0000

these issues I will mention in case they are related to this: also, possibly separate is a memcache php error i keep getting. seems like it could be related to this thread? http://framework.zend.com/issues/browse/ZF-11463 [02-Aug-2011 10:16:23] PHP Fatal error: Call to a member function getValue() on a non-object in /usr/share/pear/Horde/Themes/Element.php on line 114 [02-Aug-2011 10:16:23] PHP Fatal error: Undefined class constant 'MAX_SIZE' in /usr/share/pear/Horde/Memcache.php on line 324 I also get this problem every while in the log.. uamail HORDE: HORDE [imp] IMP_Imap: Invalid method call "listMailboxes". [pid 20385 on line 328 of "/var/www/html/home/imp/lib/Imap.php"] but that may be from people failing to log in?

the attachment I left is using a second folder copy of our h

Tue, 02 Aug 2011 15:20:51 +0000

the attachment I left is using a second folder copy of our home directory (where horde is located) but with file logging on and memcache off... normally we use memcache and it just looks like it has constant errors with that max_size.. but anyway, that's unrelated to the question at hand

This is the only important information: > [02-Aug-2011 10

Tue, 02 Aug 2011 22:29:59 +0000

This is the only important information: > [02-Aug-2011 10:16:23] PHP Fatal error: Call to a member function > getValue() on a non-object in > /usr/share/pear/Horde/Themes/Element.php on line 114 No idea how this could happen. We would need a backtrace, and you should watch out for earlier errors leading to that fatal error. > [02-Aug-2011 10:16:23] PHP Fatal error: Undefined class constant > 'MAX_SIZE' in /usr/share/pear/Horde/Memcache.php on line 324 And this doesn't make *any* sense at all. That constant *is* defined in that very file.

>> [02-Aug-2011 10:16:23] PHP Fatal error: Undefined class

Tue, 02 Aug 2011 22:43:21 +0000

>> [02-Aug-2011 10:16:23] PHP Fatal error: Undefined class constant >> 'MAX_SIZE' in /usr/share/pear/Horde/Memcache.php on line 324 > > And this doesn't make *any* sense at all. That constant *is* defined > in that very file. Can't recall the ticket where this has previously been discussed... but if PHP fatal errors during the session init, this error occurs. It either has something to do with APC, autoloading, or a custom session handler. In any case, it is irrelevant - it simply means that PHP fataled during initialization.

well, the php error only happens when we use memcache, but t

Tue, 02 Aug 2011 23:10:13 +0000

well, the php error only happens when we use memcache, but the problem I originally mentioned involving the prefs (and possibly only last_logintasks) happens with memcache being used or not. (and when not, the error does not happen as seen in the log attached) so my question is, What sets last_logintasks ?

> uamail HORDE: HORDE [imp] IMP_Imap: Invalid method call

Mon, 08 Aug 2011 19:10:39 +0000

> uamail HORDE: HORDE [imp] IMP_Imap: Invalid method call > "listMailboxes". [pid 20385 on line 328 of > "/var/www/html/home/imp/lib/Imap.php"] but that may be from people > failing to log in? This issue is what this commit was trying to fix: commit 7a5e21b88440674ba15d70f6c12d87f9aa71fab2 Author: Michael M Slusarz Date: Thu Aug 4 12:36:02 2011 -0600 Work around sporadic error on re-authentication to imp This is a total hack, but I can't figure out why this is happening. It only happens on a logout -> relogin, so it might have something to do with an inconsistent session state during the logout phase. Notable is that I can not reliably reproduce. One theory: One of the long running actions (e.g. listing a mailbox) is in process, logout is called, and the long running process will write an inconsistent session when it reinits the session.

> Notable is that I can not reliably reproduce. One theor

Mon, 08 Aug 2011 19:22:01 +0000

> Notable is that I can not reliably reproduce. One theory: One of the > long running actions (e.g. listing a mailbox) is in process, logout > is called, and the long running process will write an inconsistent > session when it reinits the session. FWIW, I can reproduce this fairly consistently when I purposely change the user agent on my browser while testing ourmobile views. When the session is terminated due to the user agent check failing, logging back in almost always produces this error for me.

> One theory: One of the > long running actions (e.g. list

Mon, 08 Aug 2011 19:54:33 +0000

> One theory: One of the > long running actions (e.g. listing a mailbox) is in process, logout > is called, and the long running process will write an inconsistent > session when it reinits the session. I can verify that this was the issue (at least with IMP). For example, clicking on a long running listMailboxes operation (e.g. opening a very large trash mailbox) and then clicking on logout while this request was still pending would result in an imp/ entry to be created in the non-authenticated session when the original process eventually reopened the session. The changes to Horde_Session fix this - sessions are marked as read-only in an access if, when reopened, the authentication status has changed. I have no idea if this fixes the user-agent string issue.

Changes have been made in Git for this ticket: Bug #10403:

Mon, 08 Aug 2011 19:55:41 +0000

Changes have been made in Git for this ticket: Bug #10403: Fix Bug Number 1 files changed, 3 insertions(+), 3 deletions(-) http://git.horde.org/horde-git/-/commit/705e7db4801233a5713b0c43c4eba79e25b46d75

> I have no idea if this fixes the user-agent string issue.

Wed, 10 Aug 2011 22:30:39 +0000

> I have no idea if this fixes the user-agent string issue. For the record, it doesn't. Though this shouldn't really happen in normal usage anyway.

Changes have been made in Git for this ticket: Bug #10403:

Wed, 17 Aug 2011 04:15:06 +0000

Changes have been made in Git for this ticket: Bug #10403: Never save IMAP object when we are not authenticated 1 files changed, 5 insertions(+), 3 deletions(-) http://git.horde.org/horde-git/-/commit/3eeefeea234002f826f4da84638c14e25559c9f2

>> I have no idea if this fixes the user-agent string issue.

Wed, 17 Aug 2011 04:16:20 +0000

>> I have no idea if this fixes the user-agent string issue. > > For the record, it doesn't. Though this shouldn't really happen in > normal usage anyway. Except if it ever does, it shouldn't break things, no matter how rare. Figured it out though and this is now completely fixed.