Last modified: 2011-04-30 01:16:47 UTC
Problem: ================== When I set Monobook as default skin (or other skin based on Monobook template), MediaWiki crashes everytime I click in Login/Create an Account link. Configuration: ================== # Windows Vista SP1 # IIS Server 6.0 # MediaWiki 1.14.0 # PHP Version 5.2.6 # MySQL 5.1.26 Error message: ================== MediaWiki internal error. Original exception: exception 'MWException' with message 'SkinTemplate::makeTalkUrlDetails given invalid pagename User:' in C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php:624 Stack trace: #0 C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php(564): SkinTemplate->makeTalkUrlDetails('User:') #1 C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php(434): SkinTemplate->buildPersonalUrls() #2 C:\inetpub\wwwroot\intranet\wiki\includes\OutputPa ge.php(945): SkinTemplate->outputPage(Object(OutputPage)) #3 C:\inetpub\wwwroot\intranet\wiki\includes\Wiki.php (342): OutputPage->output() #4 C:\inetpub\wwwroot\intranet\wiki\index.php(115): MediaWiki->finalCleanup(Array, Object(OutputPage)) #5 {main} Exception caught inside exception handler: exception 'MWException' with message 'SkinTemplate::makeTalkUrlDetails given invalid pagename User:' in C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php:624 Stack trace: #0 C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php(564): SkinTemplate->makeTalkUrlDetails('User:') #1 C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php(434): SkinTemplate->buildPersonalUrls() #2 C:\inetpub\wwwroot\intranet\wiki\includes\OutputPa ge.php(945): SkinTemplate->outputPage(Object(OutputPage)) #3 C:\inetpub\wwwroot\intranet\wiki\includes\Exceptio n.php(159): OutputPage->output() #4 C:\inetpub\wwwroot\intranet\wiki\includes\Exceptio n.php(183): MWException->reportHTML() #5 C:\inetpub\wwwroot\intranet\wiki\includes\Exceptio n.php(269): MWException->report() #6 C:\inetpub\wwwroot\intranet\wiki\includes\Exceptio n.php(327): wfReportException(Object(MWException)) #7 [internal function]: wfExceptionHandler(Object(MWException)) #8 {main} Overview: ================== It is a strange behavior: using Monobook skin, MediaWiki creates a cookie named "wikidb_session". This cookie holds some configuration and its is the responsible for crashes the interface when click "Login/Create an Account link". After the problem, all pages crashes for complete. If I delete the cookie, interface runs again. But, as soon I click the login link again, interface crashes. This problem only happens with Monobook skin and some other skins using Monobook as template skin. Done: ================== I disabled accept cookies in browser. Problem still happens when i click the link. But, now, without the cookie, all other pages runs perfectly. Something are been trying to be generated when I click login link. I read in a forum something about this. I read about MediaWiki are trying to create a page, but it does not exist (Special:User). I can't confirm because i don't know MediaWiki functions deeply yet. I am studying. I've done some tests last night, but without success. I copied all variables from "DefaultSettings.php", one by one, analyzed each one, and pasted into "LocalSettings.php" testing different values and it results. What was "false" by default, i tried "true" and vice-versa. And nothing, absolutely nothing, make any difference. Of course, some configurations cause MediaWiki stop for complete, but i cant solve this issue mentioned in this post. Still looking for and going to Bugzilla to post this bug.
This appears to be a regression, I tested this with an earlier version I still had save (1.9.2) and I did not get this exception.
MW 1.10.0 is the first version I observe this exception in, although it is handled gracefully. MW 1.14.0 just pukes on the exception. Here are the details from 1.10.0 SkinTemplate::makeTalkUrlDetails given invalid pagename User: Backtrace: #0 C:\inetpub\wwwroot\wiki.10\includes\SkinTemplate.php(561): SkinTemplate->makeTalkUrlDetails('User:') #1 C:\inetpub\wwwroot\wiki.10\includes\SkinTemplate.php(436): SkinTemplate->buildPersonalUrls() #2 C:\inetpub\wwwroot\wiki.10\includes\OutputPage.php(676): SkinTemplate->outputPage(Object(OutputPage)) #3 C:\inetpub\wwwroot\wiki.10\includes\Wiki.php(296): OutputPage->output() #4 C:\inetpub\wwwroot\wiki.10\index.php(90): MediaWiki->finalCleanup(Array, Object(LoadBalancer), Object(OutputPage)) #5 {main} It is the same first exception as 1.14, however, there is not a second exception thrown in the exception handler as in 1.14
Minor correction to the previous update: MW 1.10.0 only handles the Exception gracefully the first time you encounter it when requesting the login page, the data in the cookie causes the second exception and the puke of trace details when requesting any other page afterwards, until the browser cache is cleared. I further tested against 1.9.6 (which appears to be the last version prior to 1.10.0) and I did not get this exception at first. When I accessed the login page a second time (without logging in the first time) I get this exception: PHP Fatal error: Call to a member function getTalkPage() on a non-object in C:\inetpub\wwwroot\wiki\includes\SkinTemplate.php on line 607 This prompted me to test again in 1.9.2 which was the version I started with, and I get the same behavior with this new exception. I'm beginning to think no version will work on this environment. Here are my testing environment details: Windows Server 2008 IIS Server 7 PHP Version 5.2.9-1 (IIS FastCGI) MySQL 5.0.26-community-nt I'm leaning towards an OS-level problem, because Server 2008 is almost the same at its core as Vista. And they are both very different from previous Windows OSs.
Hum, interesting posts. Problem occur in Windows Vista and Windows Server 2008. I have an old machine here with Windows XP. Maybe i can try to install this environment and see if MW crashes in Windows 2000 Professional too. Phillip, as you said in your latest post, only clearing the cache of the browser you will can access other pages after the first exception. Until you clear the cache, all pages are crashing after the first crash. I will run some tests with Windows 2000 Professional SP4, the most stable of all Windows, in my opinion.
Reproduced: Server is FreeBSD 7.1-RELEASE-p4, Apache 1.3.41, PHP 5.29 (mod_php), MySql 5.0.77 (MyISAM), MW 1.14.0 Does not occur on IE 7 nor recent Firefox, only occurs on Safari 4 (don't have Safari 3 around to test), Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; en) AppleWebKit/528.18.1 (KHTML, like Gecko) Version/4.0 Safari/528.17 Workaround... $wgDefaultSkin = 'standard'; in LocalSettings.php
Update... I can reproduce this with Safari 4 beta *and* [Firefox Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10] only when utilizing a Squid 3.0/STABLE9 proxy. Problem does not occur when using direct IP connectivity nor through another vendor's (BlueCoat) proxy. I wonder if a proxy in the mix is common to my problem and the others who have reported it.
Response via Squid/3.0.STABLE9 for GET http://wiki.0x1.net/index.php?title=Special:UserLogin&returnto=Main_Page : (note: disabled gzip,deflate on browser for these tests) HTTP/1.0 200 OK Date: Thu, 04 Jun 2009 21:53:25 GMT Server: Apache Set-Cookie: db_mediawiki_session=f9360da5114ea391ec1223e3afd2f71e; path=/; HttpOnly Content-Language: en Vary: Accept-Encoding X-Vary-Options: Accept-Encoding;list-contains=gzip Content-Length: 1703 Content-Type: text/html; charset=UTF-8 X-Cache: MISS from antenora.aculei.net Via: 1.0 antenora.aculei.net (squid/3.0.STABLE9) Proxy-Connection: keep-alive MediaWiki internal error.<br /> ... ... ... etc. Response when direct: HTTP/1.0 200 OK Date: Thu, 04 Jun 2009 22:03:18 GMT Server: Apache Set-Cookie: db_mediawiki_session=8c482a532baf758dfd44f906ec538a86; path=/; HttpOnly Content-Language: en Vary: Accept-Encoding,Cookie X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string-contains=db_mediawikiToken;string-contains=db_mediawikiLoggedOut;string-contains=db_mediawiki_session Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: private, must-revalidate, max-age=0 Content-Length: 9953 Content-Type: text/html; charset=UTF-8 Connection: keep-alive <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> ... ... ... etc. proper login document follows Is this some sort of strange cache directive issue? Note: these are the responses from the point of view of the browser... I cannot do a packet capture on this server sadly.
It turned out that this was occurring on my installation due to hosting provider local-wonkyness. Hosting provider (nearlyfreespeech.net) was rewriting the REMOTE_ADDR environment variable to facilitate their reverse proxies being "transparent" to scripts that were unfamiliar with interpreting X-Forwarded-For headers. The unintended side affect of this was that when external proxies were also present, REMOTE_ADDR looked something like "127.0.0.1, 44.68.10.10", which is not normal. Mediawiki choked on this. A locally relevant patch was applied, resolving the issue. YMMV, this may not be the same issue the others are experiencing. But check your REMOTE_ADDR anyway (by way of phpinfo() perhaps?). That said, MediaWiki should likely not puke when presented with a malformed REMOTE_ADDR.
(In reply to comment #8) > That said, MediaWiki should likely not puke when presented with a malformed > REMOTE_ADDR. > Updating summary accordingly.
Fixed in r51725
Reverted in r51774. Faking IPs is bad. Instead, we'll try to get the IP as best as possible from REMOTE_ADDR or HTTP_X_FORWARDED_FOR. Barring that, we cannot proceed without an IP address. An exception is now thrown if the IP cannot be determined.
I have experienced this happening as well on my MediaWiki 1.15.1 installation and seemed to be caused by REMOTE_ADDR returning an IPv6 address. I'm guessing this is not supported by MediaWiki. As a workaround I included the following option in my local settings file to disable the display of IP address in the header when not logged in: $wgShowIPinHeader = false;
