Last modified: 2012-06-07 15:00:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36819, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34819 - [MySQL] Possibility for confusing error messages upon opening connection, while background connection is open
[MySQL] Possibility for confusing error messages upon opening connection, whi...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.20.x
All All
: Normal trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-29 23:20 UTC by christian
Modified: 2012-06-07 15:00 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Correct MySQL connection error messages (855 bytes, patch)
2012-02-29 23:20 UTC, christian
Details

Description christian 2012-02-29 23:20:33 UTC
Created attachment 10134 [details]
Correct MySQL connection error messages

When creating a DatabaseMysql object "dbB" (whose connection fails), while in the background another MySQL connection's previous action resulted in an error, dbB's creation fails with the background connection's error message.

Consider

------8<---Begin---
 $dbA=new DatabaseMysql($wgDBserver,$wgDBuser,$wgDBpassword,$wgDBname);
 $dbA->selectDB( "non_existing_database" );

 wfDebug( "----------------------------\n" );

 $wgDBuser = $wgDBuser."someText";
 $dbB = wfGetDB( DB_MASTER );
------8<---End---

Connection for $dbA succeeds. Then a non existing database is selected.
Connection for $dbB fails, as the credentials are wrong on purpose.

The log messages for the $dbB connection failure however show:

------8<---Begin---
DB connection error
Server: localhost, User: wikisvnsomeText, Password: wik..., error: Access denied for user 'wikisvn'@'localhost' to database 'non_existing_database'
------8<---End---

Note the part /after/ the "error:".

Same for the DB log:
------8<---Begin---
Wed Feb 29 23:11:13 UTC 2012    spencer wikisvn Error connecting to localhost: Access denied for user 'wikisvn'@'localhost' to database 'non_existing_database' (localhost)
------8<---End---

The attached patch uses mysql_error only as fallback and produces the following log:

------8<---Begin---
DB connection error
Server: localhost, User: wikisvnsomeText, Password: wik..., error: Access denied for user 'wikisvnsomeText'@'localhost' (using password: YES)
------8<---End---

and the following DB log:

------8<---Begin---
Wed Feb 29 23:14:01 UTC 2012    spencer wikisvn Error connecting to localhost: Access denied for user 'wikisvnsomeText'@'localhost' (using password: YES)
------8<---End---

Both, log and DB log, show the expected error message after applying the patch.
Comment 1 Mark A. Hershberger 2012-03-01 15:19:00 UTC
adding Chad to ask him to look at this patch
Comment 2 Brion Vibber 2012-04-17 17:43:35 UTC
I understand switching from mysql_error() to $error, but why the swapping of the priorities between the slurped PHP error and the checking for immediate errors? It seems a bit unclear to me.
Comment 3 christian 2012-04-17 18:17:36 UTC
(In reply to comment #2)
> but why the swapping of
> the priorities between the slurped PHP error and the checking for immediate
> errors?

This switch arranges that:
* dbA reports only the errors of dbA, and
* dbB reports only the errors of dbB.
Without this switch, dbB's failed connection attempt would yield dbA's "database selection" error

The culprit for this mismatch is lastError().
dbB does not have a proper mConn set, when lastError() is called on it (See the guarding "if" condition). Hence, this lastError() call comes down to calling mysql_error() without parameters. However, calling mysql_error() without parameters refers to the previously (successfully) opened connection (In our case: dbA).

So without the switch, dbB reports the error message of dbA instead of it's own error message (see the logs in bug description).
Comment 4 Sumana Harihareswara 2012-05-25 02:22:34 UTC
Hi, Christian!  Thanks for the patch.  Maybe you could use Developer
access https://www.mediawiki.org/wiki/Developer_access to submit your patch
directly into Git and Gerrit, so it'll get reviewed faster.  Thanks.
Comment 5 christian 2012-05-28 20:22:37 UTC
(In reply to comment #4)
> Maybe you could [...] to submit your patch
> directly into Git and Gerrit [...]

Done.
Gerrit: https://gerrit.wikimedia.org/r/#/c/9202/1
Comment 6 christian 2012-06-07 15:00:35 UTC
Merged upstream in git commit af919fe3e0c9c847de0ebbeea3659186be9d541d

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links