Are you able to reproduce this on this bug tracker?

i got the same problem:
when i reset a report's password in a computer logined with administrator. At the same computer i receive the validate email and click the url to reset the password. Then the report login with new password(not administrator), the browser will never got response.
php log shows:
[21-Dec-2009 17:07:20] PHP Fatal error: Maximum execution time of 60 seconds exceeded in C:\mantisbt-1.1.8\core\session_api.php on line 75

when the error happened, it didn't work just closing the browser and logining again. But the other user on another computer is ok(no reseting operation).

my software on windows xp:
mantis 1.1.8 with phpmailer (gmail)
php 5.3.1
apache 2.2
mysql 5.1

We have the same problem here, session_start hangs sometimes.

I am not able to reproduce it reliably.

If possible try php 5.2 not php 5.3.1 first

i tried iis6.0+mantis1.1.8+php5.2.12, everything's ok now.

Cant change back to php 5.2, since this means changing back to apache 2.2.11, which means that mod_svn etc. wont work anymore.

I wonder why other php applications using sessions work well. (on the same server, i am hosting a mediawiki instance, which is working well)

I have the same environment and I can confirm a similar behaviour (using PHP 5.3.1). Not sure how to fix it ...

What can we do, to support a fix for this problem?

We're having the same problem. We can login sporadically (randomly) to MantisBT, other PHP applications (DokuWiki), work fine. It's just MantisBT.

Two of us have seen the following timeout message, my coworker in Safari on his Mac, me in IE8 on a PC:

PHP Fatal error: Maximum execution time of 120 seconds exceeded in C:\mantisbt\core\session_api.php on line 75

Line 75 is:

 $this->id = session_id();

We both tried clearing all browsing info/cache, and my coworker was able to login, he doesn't want to logout (he's in Safari), because he says he won't be able to login back in. Me in IE8 on the PC, I just can't login.

Anyone know what's going on?

Server Hardware: Dell PowerEdge 860

Server Software:
Windows 2003 R2 Enterprise SP2
PHP 5.3.1
Apache 2.2
MantisBT 1.1.8

Maybe someone is able to reproduce this in an environment which can be easliy set up by a developer.
I am trying to reproduce this problem with the current version of XAMPP (1.7.3, which includes PHP 5.3.1) but until now I had no success.

After the session on the admin panel obsolete - need to re-enter your password - if you enter the wrong password, the Mantis is frozen until you manually delete the session PHPSESSID

My workaround is to manually delete all browsing data in IE8 on exit. But that doesn't work very often, so I'm not even sure if that's doing anything...

When I have logged in, and I hit logout, it take a long time to log out, but I can then log in. If I close the browser while I'm logged in, then I can't log back in, kind of like the user is poisoned.

dotKenny, what did you mean manually delete my session PHPSESSID? I'd like to try it to troubleshoot. What do you recommend?

My problem exists on two machines with XAMPPlite 1.7.2 + mantis 1.1.8.
It is also sometimes manifests itself when trying to leave a comment.
manually delete = Firecookie can delete session.

Hello World.

I'm having same issue but just when using my corporate proxy for accessing Mantis. When disabling proxy access for our Mantis IP address everything works fine.

I think this problem is related/similar to this one from me:
http://www.mantisbt.org/bugs/view.php?id=11535

Got all the described scenarios at my mantis 1.2.0 version, but without the log entry.

Additionally i found out, that if you disable cookies. You can open the site again after the failure occured. So that is a workaround until the bugfix is available.

I think it is really a server ISA, after I configured time_out in scripts Mantis (which by the way in Win also now works), Mantis never again frozen. So it seems the problem has been hanging in the "difficult" sending letters.

Look for bugfixing at this article:

http://www.mantisbt.org/bugs/view.php?id=11535

Seems to be a duplicate of 0011535.