6.0.0-git
2019-04-24

[#10403] prefs bug possibly
Summary prefs bug possibly
Queue IMP
Queue Version 5.0.8
Type Bug
State Resolved
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester whatdoyouwant (at) gmail (dot) com
Created 2011-08-02 (2822 days ago)
Due
Updated 2011-08-17 (2807 days ago)
Assigned 2011-08-02 (2822 days ago)
Resolved 2011-08-17 (2807 days ago)
Milestone
Patch No

History
2011-08-17 04:16:20 Michael Slusarz Comment #14
Assigned to Michael Slusarz
State ⇒ Resolved
Reply to this comment
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.
2011-08-17 04:15:06 Git Commit Comment #13 Reply to this comment
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
2011-08-10 22:30:39 Michael Rubinsky Comment #12 Reply to this comment
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.
2011-08-08 19:55:41 Git Commit Comment #11 Reply to this comment
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
2011-08-08 19:54:33 Michael Slusarz Comment #10 Reply to this comment
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.
2011-08-08 19:22:01 Michael Rubinsky Comment #9 Reply to this comment
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.

2011-08-08 19:10:39 Michael Slusarz Comment #8 Reply to this comment
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 <slusarz@curecanti.org>
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.
2011-08-02 23:10:13 whatdoyouwant (at) gmail (dot) com Comment #7 Reply to this comment
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 ?
2011-08-02 22:43:21 Michael Slusarz Comment #6 Reply to this comment
[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.
2011-08-02 22:29:59 Jan Schneider Comment #5
State ⇒ Feedback
Priority ⇒ 1. Low
Reply to this comment
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.
2011-08-02 15:20:51 whatdoyouwant (at) gmail (dot) com Comment #4 Reply to this comment
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
2011-08-02 15:18:22 whatdoyouwant (at) gmail (dot) com Comment #3 Reply to this comment
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?
2011-08-02 14:55:32 whatdoyouwant (at) gmail (dot) com Comment #2 Reply to this comment
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;}
2011-08-02 14:49:50 whatdoyouwant (at) gmail (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ prefs bug possibly
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
New Attachment: hordeprefsbug.txt Download
Reply to this comment
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.

Saved Queries