[Tue Mar 04 15:59:15 2014] [error] [client 10.14.1.172 == localhost]
PHP Warning: Cannot modify header information - headers already sent in /includes/WebResponse.php on line 38
Version: 1.23.0
Severity: normal
[Tue Mar 04 15:59:15 2014] [error] [client 10.14.1.172 == localhost]
PHP Warning: Cannot modify header information - headers already sent in /includes/WebResponse.php on line 38
Version: 1.23.0
Severity: normal
git log:
commit eb08c769b0f0076d1e849d0dabcf15dcabf2d246
Merge: 5b52c88 6ba458a
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date: Tue Mar 4 13:23:06 2014 +0000
Merge "Split date and time in message 'rclistfrom'"
I can't reproduce (running on precisely eb08c769b0f0076d). Are you sure you don't just have a BOM/extra whitespace in your LocalSettings.php or some extension, or have a closing ?> somewhere in an extension?
(In reply to Bawolff (Brian Wolff) from comment #2)
I can't reproduce (running on precisely eb08c769b0f0076d). Are you sure you
don't just have a BOM/extra whitespace in your LocalSettings.php or some
extension, or have a closing ?> somewhere in an extension?
Before "git pull", I had no warnings in my error log. I disabled all my extensions => same error.
using bisect I determined that the problem is introduced by this commit
commit 830eb262fe76ef3ad49f91daad5e152af8ce9bc4
Merge: 25466a0 9e66a63
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date: Fri Feb 28 02:19:02 2014 +0000
Merge "Use inContentLanguage for dropdown messages in HTMLFormField"
Previous version #9366a63af triggers no warnings in the log file.
The problem is still persistent in HEAD of today, i.e.
commit a72ca3e216e83bf4025ec780f62d02959afa89d9
Merge: a0cff76 ee5047c
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date: Wed Mar 5 09:06:35 2014 +0000
Merge "mediawiki.debug: Migrate CSS to LESS"
Summary:
Let's all try to find what is caused by
commit 830eb262fe76ef3ad49f91daad5e152af8ce9bc4
Merge: 25466a0 9e66a63
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date: Fri Feb 28 02:19:02 2014 +0000
Merge "Use inContentLanguage for dropdown messages in HTMLFormField"
Addition:
it seems to be caused by the *MERGE* of 9e66a63af83427a01d66795ac64b793ff4473218
commit 830eb262fe76ef3ad49f91daad5e152af8ce9bc4 ==> NOT OKAY (trigegrs warning)
Merge: 25466a0 9e66a63
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date: Fri Feb 28 02:19:02 2014 +0000
Merge "Use inContentLanguage for dropdown messages in HTMLFormField"
commit 9e66a63af83427a01d66795ac64b793ff4473218 ==> OKAY
Author: Marius Hoch <hoo@online.de>
Date: Fri Feb 28 03:12:10 2014 +0100
Use inContentLanguage for dropdown messages in HTMLFormField to restore b/c for now. Bug: 61942 Change-Id: I2741ef940d83eeb564e89e20378fb4004cfe5b83
André, I think, I have then to post in the mailing list, if anyone else ses this.
I have the very same in a totally different installation, when running versions after the mentionend ones.
I think, the problem is somewhere created in _this_ merge:
You should bisect on master. This diff is between a merge commit and the commit that has been merged (i.e. the first commit is on master, the second is not). The diff then gives you all the changes that have been merged between the start and end of the development of commit 9e66a, which is not that helpful.
Anyway, this seems to be only important change in the diff:
http://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/2ea4d7
which modifies how the job queue is triggered from a page request. If that causes the notice, you will need a non-empty job queue to reproduce it.
(In reply to Tisza Gergő from comment #7)
You should bisect on master....
Anyway, this seems to be only important change in the diff:
http://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/2ea4d7
which modifies how the job queue is triggered from a page request. If that
causes the notice, you will need a non-empty job queue to reproduce it.
Tisza: thx for your good tips. I will check today, whether the job queues are empty or not and report here later.
I checked the job queues on all my wikis with "php showJobs.php" ==> result: 0
so it has apparently nothing to do with the number of scheduled job.
What else would you suggest me to check?
Change 118336 had a related patch set uploaded by Aaron Schulz:
Avoid header notice log spam from RunJobs API
(In reply to T. Gries from comment #9)
I checked the job queues on all my wikis with "php showJobs.php" ==> result:
0
so it has apparently nothing to do with the number of scheduled job.
It has nothing to do because of bug 60210
thank you so much for fixing this, and saving my logfiles, and the rain forest and ...