Item14142: Internal server error on login screen
Priority: Urgent
Current State: No Action Required
Released In: n/a
Target Release: n/a
Applies To: Engine
Component:
Branches:
When on the login screen and I try to access
ResetPassword or
UserRegistation I sometime get "internal server error". This problem happens intermittently.
Is there a reason why I get this error once in a while?
--
IvanDebono - 13 Aug 2016
We need more information. Can you review your Foswiki and web server (apache?) logs after the error? Generally for internal server errors, we need the "stack trace" that shows the module and line that failed and the sequence of "callers".
--
GeorgeClark - 15 Aug 2016
The apache error.log:
mod_fcgid: stderr: Malformed UTF-8 (U+FFFD) in pattern match (m//) at /var/www/foswiki/lib/Foswiki.pm line 1718
--
IvanDebono - 15 Aug 2016
The last entry in the foswiki error log:
warning | Foswiki::Plugins::InterwikiPlugin |
InterwikiPlugin: user 'guest' did not have persmission to read the rules topic at 'System.InterWikis' |
--
IvanDebono - 15 Aug 2016
Malformed UTF-8 (U+FFFD)
is the issue. It appears that one of your topics contains some bytes that are not valid Unicode. Did you migrate your data from a Foswiki 1.1 or 1.0 system? (Or TWiki?) The particular line 1718 is attempting to "normalize" a "webname.topicname" string and break it out into the web and topic component parts.
Support.Utf8MigrationConsiderations#Finding_invalid_utf_458_data has information on how to find invalid data
inside a topic. Unfortunately we can't really tell where the string came from. It could be a topic name, or topic contents that is evaluated through a macro. The stack trace ... what was the full sequence of callers that led up to
Foswiki::normalizeWebTopicName
might tell a bit more.
--
GeorgeClark - 15 Aug 2016
No data migration. It's based on the 2.1.2 vmware image. This happens user registration so there are no custom topics being used.
--
IvanDebono - 15 Aug 2016
Okay, we'll look into it. Thanks.
--
GeorgeClark - 15 Aug 2016
I'm unable to recreate the issue. Booted the VM and followed links from bin/logon to the password reset, and/or registration pages, and no hint of any errors. Can you provide a more complete stack trace? (the "called by" lines related to the crash).
You could add the following line to
/var/www/foswiki/lib/Foswiki.pm
around line 1718.
sub normalizeWebTopicName {
my ( $this, $web, $topic ) = @_;
ASSERT( defined $topic ) if DEBUG;
print STDERR Data::Dumper::Dumper( \$topic ); #<<<< Add this line
This will be
very noisy in the logs, but you should be able to see the last call data just prior to the crash. After you edit the file, you need to restart apache to refresh the fcgi handlers.
--
GeorgeClark - 15 Aug 2016
Ah... before you go to that trouble, what extensions have you installed. It might be an extension that is not handling utf8 / unicode correctly.
--
GeorgeClark - 15 Aug 2016
Plugins installed:
ClassificationPlugin,
NatSkin,
NatSkinPlugin.
I have a feeling that this problem is related to
Tasks.Item14144 because a fresh vmware doesn't cause any problems.
A number of users will be registering and I will report if restoring the original site permissions solved the messed up permissions caused by using the buggy
WebPermissions plugin.
--
IvanDebono - 15 Aug 2016
There is a possibility that this could also be a Perl bug if you are on 5.20. See
https://rt.perl.org/Public/Bug/Display.html?id=122148.
--
GeorgeClark - 22 Aug 2016
If you have resolved this issue, please set the status to "No Action". Thanks.
--
GeorgeClark - 10 Sep 2016