I was able to generate similar errors by throwing an uncaught exception during the install

Change 112243 had a related patch set uploaded by Brian Wolff:
Do not use OutputPage to output exceptions in Installer

https://gerrit.wikimedia.org/r/112243

From IRC we determined the original error was due to a permissions issue. Installer should be detecting that, and not simply throwing exceptions.

Change 112243 merged by jenkins-bot:
Do not use OutputPage to output exceptions in Installer

https://gerrit.wikimedia.org/r/112243

Patch was merged a while ago - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?

Yes. Permission errors should be handled gracefully instead of dying in an exception.

We are aiming for 1.23 on this one. It would be good to get a patch to fix the issue Brian raised this week.

What is the permission problem? File system or database? Can anyone reproduce it without injecting an error through artificial means? Now that the error handling code has been changed, what error is produced?

Brian,

Could you update this bug with more details in response to Jeff's questions?

This happens, for instance, when the database already exists but the user doesn't have appropriate permissions. (Actually, I can't imagine what else could go unhandled in setupDatabase() looking at the code.)

Output of the installer in this case:

• Setting up database... A database query error has occurred. This may indicate a bug in the software.
  • Query: CREATE DATABASE calwikiCHARACTER SET utf8
  • Function: MysqlInstaller::setupDatabase
  • Error: 1044 Access denied for user 'calvin'@'%' to database 'calwiki' (localhost) Backtrace: [...]

Upon undoing gerrit 112243, a bunch of "Cannot modify header information"s appears, as described in OP, crowned by a "Fatal error: Call to a member function isSpecialPage() on a non-object in E:\www\mediawiki\includes\Skin.php on line 282"

OK, I can reproduce this by creating an unprivileged mysql user:

create user jeff@localhost identified by 'foo';

I then providing that user and password as the "User account for installation".

The ungracefulness of the error goes back at least to 1.17, although the exact details differ.

I don't know how to fix it, as this error means you would have to go back four pages in the web installation process, and I don't know how to make that happen.