TL;DR - We have reduced the amount of runtime warnings during testing by 90%.
As of today we are down to 66K warnings during linux64 debug testing; this is
down from >600K back in June. There are bugs on file for most of the remaining
top offenders blocking tracking bug 765224 [1]. It's time to
On 2015/06/17 8:29, Eric Rahm wrote:
An update on progress. I've landed bugs which should clean up ~180,000
warnings. I have bugs pending for another ~26,000.
The latest top 40:
*Note: I improved my normalization a bit so it might look a bit different
Are there documents explaining why
thes
On Wednesday, June 17, 2015 at 6:49:00 AM UTC-7, kgu...@mozilla.com wrote:
> > 4606 [N] WARNING: No widget found in TabParent::UpdateDimensions: file
> > dom/ipc/TabParent.cpp, line 974
>
> Do you know if this one occurs on b2g or also on other platforms? I added
> this warning recently in
On Wednesday, June 17, 2015 at 7:40:14 AM UTC-7, Milan Sreckovic wrote:
> Do we have a all encompassing meta bug to collect all of the bugs that fix
> the warnings?
> --
> - Milan
>
Bug 765224
___
dev-platform mailing list
dev-platform@lists.mozilla.or
Do we have a all encompassing meta bug to collect all of the bugs that fix the
warnings?
—
- Milan
On Jun 16, 2015, at 19:29 , Eric Rahm wrote:
> An update on progress. I've landed bugs which should clean up ~180,000
> warnings. I have bugs pending for another ~26,000.
>
> The latest top 40
> 4606 [N] WARNING: No widget found in TabParent::UpdateDimensions: file
> dom/ipc/TabParent.cpp, line 974
Do you know if this one occurs on b2g or also on other platforms? I added this
warning recently in bug 1125325 after smaug said [1]. It seems to be happening
a lot, so we should inves
On Wed, Jun 17, 2015 at 9:29 AM, Eric Rahm wrote:
> An update on progress. I've landed bugs which should clean up ~180,000
> warnings. I have bugs pending for another ~26,000.
Lovely! Thank you. The log size changes are impressive.
> Top 40 sorted by top level directory:
I couldn't help but no
An update on progress. I've landed bugs which should clean up ~180,000
warnings. I have bugs pending for another ~26,000.
The latest top 40:
*Note: I improved my normalization a bit so it might look a bit different
18012 [N] WARNING: Subdocument container has no frame: file
layout/base/nsD
On 10/06/15 16:10, Ehsan Akhgari wrote:
> Concrete examples would help. I can't find any test in
> browser/components/sessionstore right now with an assertion annotation
> so it's hard to say what the exact issue that you saw was, but I think
> you are complaining about the lack of documentation a
I'm 99% sure we've had mis-stars on intermittent assertion oranges where
the assertion changed and nobody bothered checking the logs to notice.
Various media tests are coming to mind for when that's happened.
On 6/10/2015 10:10 AM, Ehsan Akhgari wrote:
On 2015-06-10 3:38 AM, David Rajchenbach-
On 2015-06-10 3:38 AM, David Rajchenbach-Teller wrote:
However, I do believe in the following scenario:
- oh, there is an assertion warning, it's not my fault, let's allow one
assertion;
- wait, there are a few, let's allow several;
- oh, they are intermittent, let's make it an interval;
- [at so
However, I do believe in the following scenario:
- oh, there is an assertion warning, it's not my fault, let's allow one
assertion;
- wait, there are a few, let's allow several;
- oh, they are intermittent, let's make it an interval;
- [at some point, some of the warnings are fixed, but nobody real
On 2015-06-09 8:33 AM, Robert O'Callahan wrote:
Does anyone know of a case where we had a regression that traded one
assertion for another? I don't.
I don't either. Which is why I believe that David's point, while being
perfectly valid in theory, doesn't matter a lot in practice.
Also, you
On Wed, Jun 10, 2015 at 12:34 AM, Ryan VanderMeulen
wrote:
> On 6/9/2015 8:33 AM, Robert O'Callahan wrote:
>
>> Does anyone know of a case where we had a regression that traded one
>> assertion for another? I don't.
>
>
>> How would we have found out? :)
Detecting the regression some other way
On 6/9/2015 8:33 AM, Robert O'Callahan wrote:
Does anyone know of a case where we had a regression that traded one
assertion for another? I don't.
Rob
How would we have found out? :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https:
Does anyone know of a case where we had a regression that traded one
assertion for another? I don't.
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoio
In my books, that's pretty footgunish.
On 09/06/15 04:04, Boris Zbarsky wrote:
> You can specify an exact number or a range.
>
> But you're right that you can't specify the assertion text involved...
>
> -Boris
> ___
> dev-platform mailing list
> dev-p
On 6/8/15 4:28 PM, David Rajchenbach-Teller wrote:
Last time I looked at whitelisting non-fatal assertions, there was only
the option to accept up-to a number of assertions.
You can specify an exact number or a range.
But you're right that you can't specify the assertion text involved...
-Bor
Last time I looked at whitelisting non-fatal assertions, there was only
the option to accept up-to a number of assertions. Have I missed
something? Because a blank check to sweep assertions under the carpet is
really an awful mechanism.
Now, I fully agree that warnings that are not whitelisted sho
On 2015-06-05 6:08 AM, David Rajchenbach-Teller wrote:
This API covers all the needs I have encountered for warnings so far in
JS code. I don't think it's terribly different in C++ code.
For C++ non-fatal assertions, we already have a mechanism similar to
this (but it doesn't rely on the exact
Hi,
On 2015/06/06 2:39, Eric Rahm wrote:
On Friday, June 5, 2015 at 8:23:53 AM UTC-7, ISHIKAWA,chiaki wrote:
After coping with voluminous messages in C-C TB |make mozmill| test
suite log [much smaller volume than full FF logs],
I think we should have NS_INFORMATION() macro that
prints out an in
The question is what is best: ignored warnings or ignored intermittent
oranges? I assume that the latter have the best chance of being
eventually fixed, but I'm not sure.
On 05/06/15 18:17, Ryan VanderMeulen wrote:
> Uncaught Promise rejections were made fatal and for the most part go
> ignored wh
On Friday, June 5, 2015 at 8:23:53 AM UTC-7, ISHIKAWA,chiaki wrote:
> After coping with voluminous messages in C-C TB |make mozmill| test
> suite log [much smaller volume than full FF logs],
> I think we should have NS_INFORMATION() macro that
> prints out an information for someone who is develop
Uncaught Promise rejections were made fatal and for the most part go
ignored when they fail intermittently. I'm not a huge fan of adding more
ways for tests to fail if people aren't willing to actually do something
about it when they do.
-Ryan
On 6/5/2015 6:08 AM, David Rajchenbach-Teller wro
On 2015/06/04 21:38, Robert O'Callahan wrote:
Usually I use NS_WARNING to mean "something weird and unexpected is
happening, e.g. a bug in Web page code, but not necessarily a browser bug".
Sometimes I get useful hints from NS_WARNING spew leading up to a serious
failure, but for those usages cou
My patch introduces a new Warnings mechanism for JS. If this works
nicely, I'd like to extend this to C++.
Basically, whenever you encounter a situation that should never happen
in production but that is not quite fatal enough to warrant a crash, we
call (from the top of my head)
Warnings.warn("t
On Thu, Jun 4, 2015 at 1:48 PM, Luke Wagner wrote:
> In addition to judging noisiness by volume over a whole test run, can we
> also include any warning that happens on normal browser startup, new tab,
> and other vanilla browser operations? This has always annoyed me.
Indeed. Here's an attempt
On 6/4/15 6:14 PM, Ehsan Akhgari wrote:
They are both equally slow, but fatal assertions happen only once, by
definition. ;-)
Except that for some of our tests we restart after a crash (e.g. for web
platform tests).
So in that test harness, fatal assertions that are hit are much slower
tha
On 2015-06-04 9:40 AM, David Rajchenbach-Teller wrote:
On 04/06/15 14:30, Ehsan Akhgari wrote:
There are very good reasons for warnings to not cause tests to fail. We
have a lot of tests that are testing failure conditions that are
expected to warn, because they are failure conditions.
Well,
On Thursday, June 4, 2015 at 11:14:59 AM UTC-7, Martin Thomson wrote:
> On Jun 4, 2015 10:27 AM, "Daniel Holbert" wrote:
> > Also: in layout, there are various warnings related to coordinate
> > wraparound/overflow, where we're basically throwing up our hands and
> > warning that broken layout is
On 06/05/2015 12:06 AM, Daniel Holbert wrote:
On 06/04/2015 01:18 PM, smaug wrote:
More likely we need to change a small number of noisy NS_ENSURE_* macro
users to use something else,
and keep most of the NS_ENSURE_* usage as it is.
I agree -- I posted about switching to something opt-in, like
On Thursday, June 4, 2015 at 1:48:30 PM UTC-7, Luke Wagner wrote:
> In addition to judging noisiness by volume over a whole test run, can we
> also include any warning that happens on normal browser startup, new tab,
> and other vanilla browser operations? This has always annoyed me.
Yes, this bo
On 06/04/2015 01:18 PM, smaug wrote:
> More likely we need to change a small number of noisy NS_ENSURE_* macro
> users to use something else,
> and keep most of the NS_ENSURE_* usage as it is.
I agree -- I posted about switching to something opt-in, like MOZ_LOG,
for some of the spammier layout NS
In addition to judging noisiness by volume over a whole test run, can we
also include any warning that happens on normal browser startup, new tab,
and other vanilla browser operations? This has always annoyed me.
On Thu, Jun 4, 2015 at 3:33 PM, Bobby Holley wrote:
> On Thu, Jun 4, 2015 at 1:18
On Thu, Jun 4, 2015 at 1:18 PM, smaug wrote:
> More likely we need to change a small number of noisy NS_ENSURE_* macro
> users to use something else,
> and keep most of the NS_ENSURE_* usage as it is.
>
+1.
___
dev-platform mailing list
dev-platform@li
On 06/04/2015 09:52 PM, Jonas Sicking wrote:
On Thu, Jun 4, 2015 at 5:38 AM, Robert O'Callahan wrote:
Usually I use NS_WARNING to mean "something weird and unexpected is
happening, e.g. a bug in Web page code, but not necessarily a browser bug".
Sometimes I get useful hints from NS_WARNING spew
On 06/04/2015 01:07 PM, David Rajchenbach-Teller wrote:
Part of my world domination plans are to turn warnings into something
that causes test to actually fail (see bug 1080457 & co). Would you like
to join forces?
Turning warnings into failures sounds odd (but bug 1080457 seems to be actually
On Thu, Jun 4, 2015 at 5:38 AM, Robert O'Callahan wrote:
> Usually I use NS_WARNING to mean "something weird and unexpected is
> happening, e.g. a bug in Web page code, but not necessarily a browser bug".
> Sometimes I get useful hints from NS_WARNING spew leading up to a serious
> failure.
Yup.
On Jun 4, 2015 10:27 AM, "Daniel Holbert" wrote:
> Also: in layout, there are various warnings related to coordinate
> wraparound/overflow, where we're basically throwing up our hands and
> warning that broken layout is likely to occur because the page is
> millions of pixels tall. These can be u
On 06/04/2015 05:30 AM, Ehsan Akhgari wrote:
> There are very good reasons for warnings to not cause tests to fail. We
> have a lot of tests that are testing failure conditions that are
> expected to warn, because they are failure conditions.
Also: in layout, there are various warnings related to
On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking wrote:
> FWIW, I suspect it'll be hard to put a dent in the number of warnings
> that we emit unless we either change all instances of
> NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn,
> or unless we change NS_ENSURE_SUCCESS(rv,
On 04/06/15 14:30, Ehsan Akhgari wrote:
> There are very good reasons for warnings to not cause tests to fail. We
> have a lot of tests that are testing failure conditions that are
> expected to warn, because they are failure conditions.
Well, that's why the patch linked above offers a whitelist
Usually I use NS_WARNING to mean "something weird and unexpected is
happening, e.g. a bug in Web page code, but not necessarily a browser bug".
Sometimes I get useful hints from NS_WARNING spew leading up to a serious
failure, but for those usages could probably be switched to PR_LOG without
losing
On 2015-06-04 5:49 AM, Jonas Sicking wrote:
FWIW, I suspect it'll be hard to put a dent in the number of warnings
that we emit unless we either change all instances of
NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn,
or unless we change NS_ENSURE_SUCCESS(rv, rv) to not warn.
On 2015-06-04 6:07 AM, David Rajchenbach-Teller wrote:
Part of my world domination plans are to turn warnings into something
that causes test to actually fail (see bug 1080457 & co). Would you like
to join forces?
There are very good reasons for warnings to not cause tests to fail. We
have a
Nicholas Nethercote writes:
> Do warnings (as opposed to NS_ASSERTION) do anything in tests? I don't
> think they do. If that's right, a warning is only useful if a human
> looks at it and acts on it, and that's clearly not happening for a lot
> of these.
Warnings in tests don't do anything but l
On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking wrote:
>
> It feels like right now we have three incompatible desires:
>
> * Test lots of failure cases.
> * Make errors warn in debug builds on all/most frames as the failure
> is propagated up the callstack.
> * Don't warn a lot when testing debug bu
Part of my world domination plans are to turn warnings into something
that causes test to actually fail (see bug 1080457 & co). Would you like
to join forces?
Cheers,
David
On 04/06/15 03:14, Eric Rahm wrote:
> We emit a *lot* of runtime warnings when running debug tests. I inadvertently
> trig
FWIW, I suspect it'll be hard to put a dent in the number of warnings
that we emit unless we either change all instances of
NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn,
or unless we change NS_ENSURE_SUCCESS(rv, rv) to not warn.
It feels like right now we have three incompa
Martin Thomson writes:
> I guess that most of these are as a result of actual problems,
> even if they are minor.
The ones that are actual problems would be the ones that are
harder to resolve.
In my experience, however, when I've seen many of one kind of
warning, investigation has revealed that
On Wed, Jun 3, 2015 at 6:14 PM, Eric Rahm wrote:
> I generated this list by grabbing the logs for a recent m-c linux64 debug
> run, normalizing out PIDs and timestamps and then doing some sort/uniq-fu to
> get counts of unique lines.
If your tool could be turned into a web page that runs again
We emit a *lot* of runtime warnings when running debug tests. I inadvertently
triggered a max log size failure during a landing this week which encouraged me
to take a look at what all is being logged, and what I found was a ton of
warnings (sometimes accompanied by stack traces). Most of these
52 matches
Mail list logo
