Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

2016-09-22 Thread ishikawa 
On 2016年09月23日 03:01, Andrew McKay wrote:
> Just a note that https://bugzilla.mozilla.org/show_bug.cgi?id=1303418
> is about to land and this will prevent an add-on upgrade changing the
> ID of the add-on. That's not happening in this case (the code hasn't
> landed), but just a heads up on a similar front.

Thank you for the heads up.
However, I am a mere user of TB trying to fix a few performance issues and
annoying bugs in TB, and so
the intricacies of the processing here escapes me a little bit :-)

TIA

> 
> On 22 September 2016 at 01:33, Mark Banner  wrote:
>> On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:
>>>
>>> 3:07:56 INFO -  1474488476446addons.xpi-utilsWARN
>>> addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
>>> addon ID: expected addon ID specialpow...@mozilla.org, found
>>> special-pow...@mozilla.org in manifest  ...
>>>
>>>
>>> I am not sure if this comes from the intended test.
>>> Rather it looks a configuration error.
>>> The error line seems to appear at beginning of the selected run of each
>>> test directory.
>>>
>> ...
>>>
>>> cf. 3 results from the comm-central tree:
>>> mozilla/testing/specialpowers/Makefile.in
>>> ♢7 XPI_PKGNAME = specialpow...@mozilla.org
>>
>>
>> Looks like this is different from what is specified in
>> testing/specialpowers/install.rdf - which is the dashed version, and was
>> introduced when it was rewritten last year.
>>
>> The simplest thing is probably to change the install.rdf to remove the dash
>> as then it wouldn't be changing the file name on disk - and also update the
>> other couple of instances in the tree. Probably worth a running through a
>> few tests on try just to make sure as well.
>>
>> The test infrastructure has probably got away with it due to the next
>> warning of "Could not uninstall invalid item from locked install location",
>> so it kept on using it.
>>
>> Mark
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

2016-09-22 Thread ishikawa 
On 2016年09月23日 11:42, ishikawa wrote:
> On 2016年09月22日 17:33, Mark Banner wrote:
>> On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:
>>> 3:07:56 INFO -  1474488476446addons.xpi-utilsWARN
>>> addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
>>> addon ID: expected addon ID specialpow...@mozilla.org, found
>>> special-pow...@mozilla.org in manifest  ...
>>>
>>>
>>> I am not sure if this comes from the intended test.
>>> Rather it looks a configuration error.
>>> The error line seems to appear at beginning of the selected run of each
>>> test directory.
>>>
>> ...
>>> cf. 3 results from the comm-central tree:
>>> mozilla/testing/specialpowers/Makefile.in
>>> ♢7 XPI_PKGNAME = specialpow...@mozilla.org
>>
>> Looks like this is different from what is specified in
>> testing/specialpowers/install.rdf - which is the dashed version, and was
>> introduced when it was rewritten last year.
>>
>> The simplest thing is probably to change the install.rdf to remove the dash
>> as then it wouldn't be changing the file name on disk - and also update the
>> other couple of instances in the tree. Probably worth a running through a
>> few tests on try just to make sure as well.
>>
>> The test infrastructure has probably got away with it due to the next
>> warning of "Could not uninstall invalid item from locked install location",
>> so it kept on using it.
>>
>> Mark
> 
> By changing a few install.rdf as suggested, the particular error messages
> are gone, but
> I now see different failures.
> 
> https://treeherder.mozilla.org/#/jobs?repo=try-comm-central=de72a169065a2bbb7f69a0e5420992bfca5a77ec
> 
> I am testing other patches as well, the particular patch to modify
> install.rdf is
> https://hg.mozilla.org/try-comm-central/rev/a135ec33cb11
> 
> I will investigate more to see if the new errors are due to my changes or
> a regression caused by a later change to M-C, etc.
> 
> TIA
> 

The new errors are obviously related to my change.
(linux 64 debug)
Assertion failure: IsInAutomation(), at
/builds/slave/tb-try-c-cen-l64-d-000/build/mozilla/js/xpconnect/src/xpcprivate.h:3445

(OSX 10.10 debug)
Assertion failure: IsInAutomation(), at
/builds/slave/tb-try-c-cen-m64-d-000/build/mozilla/js/xpconnect/src/xpcprivate.h:3445

(WIndows 7 debug)
Assertion failure: IsInAutomation(), at
c:\builds\moz2_slave\tb-try-c-cen-w32-d-000\build\mozilla\js\xpconnect\src\xpcprivate.h:3445

xpprivate.h:3445 is
inline void
CrashIfNotInAutomation()
{
MOZ_RELEASE_ASSERT(IsInAutomation());
}

So where is CrashIfNotInAutomation() called?
5 results from the comm-central tree: Switch Tree
mozilla/js/xpconnect/src/XPCComponents.cpp
♢ 2920 CrashIfNotInAutomation();
♢ 2931 CrashIfNotInAutomation();
mozilla/js/xpconnect/src/xpcprivate.h
♢ 3443 CrashIfNotInAutomation()
mozilla/js/xpconnect/wrappers/WrapperFactory.cpp
♢ 453 CrashIfNotInAutomation();
♢ 459 CrashIfNotInAutomation();

These places seem to try to use a different variant of XPC API or something
depending on where the code is executed (hmm, tricky and not sure if this is
a great idea in view of security), and
since the string is changed, the assertion now fails, it seems.
(Which means then, maybe I need to reverse the change of one python script,
and one JavaScript file.)

I changed only these:

diff --git a/build/mobile/b2gautomation.py b/build/mobile/b2gautomation.py
--- a/build/mobile/b2gautomation.py
+++ b/build/mobile/b2gautomation.py
@@ -89,18 +89,18 @@ class B2GRemoteAutomation(Automation):
 for rdfChild in document.documentElement.childNodes:
 if rdfChild.nodeType == Node.ELEMENT_NODE and rdfChild.tagName
== "Description":
 for descChild in rdfChild.childNodes:
 if descChild.nodeType == Node.ELEMENT_NODE and
descChild.tagName == "em:id":
 return descChild.childNodes[0].data
 return None

 def installExtension(self, extensionSource, profileDir, extensionID=None):
-# Bug 827504 - installing special-powers extension separately
causes problems in B2G
-if extensionID != "special-pow...@mozilla.org":
+# Bug 827504 - installing specialpowers extension separately causes
problems in B2G
+if extensionID != "specialpow...@mozilla.org":
 if not os.path.isdir(profileDir):
   self.log.info("INFO | automation.py | Cannot install
extension, invalid profileDir at: %s", profileDir)
   return

 installRDFFilename = "install.rdf"

 extensionsRootDir = os.path.join(profileDir, "extensions",
"staged")
 if not os.path.isdir(extensionsRootDir):
diff --git a/modules/libpref/init/all.js b/modules/libpref/init/all.js
--- a/modules/libpref/init/all.js
+++ b/modules/libpref/init/all.js
@@ -5339,17 +5339,17 @@ pref("dom.mozSettings.SettingsService.ve
 pref("dom.mozSettings.allowForceReadOnly", false);

 // The interval at which to check for slow running addons
 #ifdef

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

2016-09-22 Thread ishikawa 
On 2016年09月22日 17:33, Mark Banner wrote:
> On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:
>> 3:07:56 INFO -  1474488476446addons.xpi-utilsWARN
>> addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
>> addon ID: expected addon ID specialpow...@mozilla.org, found
>> special-pow...@mozilla.org in manifest  ...
>>
>>
>> I am not sure if this comes from the intended test.
>> Rather it looks a configuration error.
>> The error line seems to appear at beginning of the selected run of each
>> test directory.
>>
> ...
>> cf. 3 results from the comm-central tree:
>> mozilla/testing/specialpowers/Makefile.in
>> ♢7 XPI_PKGNAME = specialpow...@mozilla.org
> 
> Looks like this is different from what is specified in
> testing/specialpowers/install.rdf - which is the dashed version, and was
> introduced when it was rewritten last year.
> 
> The simplest thing is probably to change the install.rdf to remove the dash
> as then it wouldn't be changing the file name on disk - and also update the
> other couple of instances in the tree. Probably worth a running through a
> few tests on try just to make sure as well.
> 
> The test infrastructure has probably got away with it due to the next
> warning of "Could not uninstall invalid item from locked install location",
> so it kept on using it.
> 
> Mark

By changing a few install.rdf as suggested, the particular error messages
are gone, but
I now see different failures.

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central=de72a169065a2bbb7f69a0e5420992bfca5a77ec

I am testing other patches as well, the particular patch to modify
install.rdf is
https://hg.mozilla.org/try-comm-central/rev/a135ec33cb11

I will investigate more to see if the new errors are due to my changes or
a regression caused by a later change to M-C, etc.

TIA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

2016-09-22 Thread Andrew McKay 
Just a note that https://bugzilla.mozilla.org/show_bug.cgi?id=1303418
is about to land and this will prevent an add-on upgrade changing the
ID of the add-on. That's not happening in this case (the code hasn't
landed), but just a heads up on a similar front.

On 22 September 2016 at 01:33, Mark Banner  wrote:
> On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:
>>
>> 3:07:56 INFO -  1474488476446addons.xpi-utilsWARN
>> addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
>> addon ID: expected addon ID specialpow...@mozilla.org, found
>> special-pow...@mozilla.org in manifest  ...
>>
>>
>> I am not sure if this comes from the intended test.
>> Rather it looks a configuration error.
>> The error line seems to appear at beginning of the selected run of each
>> test directory.
>>
> ...
>>
>> cf. 3 results from the comm-central tree:
>> mozilla/testing/specialpowers/Makefile.in
>> ♢7 XPI_PKGNAME = specialpow...@mozilla.org
>
>
> Looks like this is different from what is specified in
> testing/specialpowers/install.rdf - which is the dashed version, and was
> introduced when it was rewritten last year.
>
> The simplest thing is probably to change the install.rdf to remove the dash
> as then it wouldn't be changing the file name on disk - and also update the
> other couple of instances in the tree. Probably worth a running through a
> few tests on try just to make sure as well.
>
> The test infrastructure has probably got away with it due to the next
> warning of "Could not uninstall invalid item from locked install location",
> so it kept on using it.
>
> Mark
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Buildbot Try artifact expiration

2016-09-22 Thread Boris Zbarsky 

On 9/22/16 2:52 PM, gar...@mozilla.com wrote:

In May it was decided that artifacts for try jobs running in TaskCluster should 
expire after 14 days.


Just to be clear, what counts as "artifacts" here?  The actual build? 
The log?  All of the above?


There may be value for keeping logs longer than that...

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

2016-09-22 Thread Ehsan Akhgari 
On 2016-09-22 9:07 AM, Gijs Kruitbosch wrote:
> On 22/09/2016 05:28, Nicholas Nethercote wrote:
>> Greetings,
>>
>> Assertions, such as MOZ_ASSERT, are great. But they only run in debug
>> builds.
>>
>> Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
>>
>> I want to highlight a nice case where converting a normal assertion
>> into a release assertion was a win. In bug 1159244 Michael Layzell did
>> this in nsTArray::ElementAt(), to implement a form of always-on array
>> bounds checking. See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
>> discussion of how this is finding real bugs in the wild. (As well as
>> identifying new bugs, it's also helping understand existing crash
>> reports, e.g. see bug 1291082 where the crash signature changed.)
>>
>> Obviously we can't convert every normal assertion in the codebase into
>> a release assertion. But it might be worth thinking about which normal
>> assertions are good candidates for conversion. Good candidates include
>> any assertion where the consequence of failure is dangerous, e.g.
>> might cause memory access violations.
>>
>> Nick
> 
> Yes please. This + diagnostic assert also helps frontend people who
> build and run opt builds (because debug builds are too slow to be
> usable, especially when combined with the browser toolbox (JS
> debugging)). Right now I miss some of these and then only find out when
> the tests that I did run go orange on try and/or inbound/autoland, and
> then I have to locally change the relevant C++ so I can test in my opt
> build (or resign myself to doing a separate clobber debug build somewhere).

What exact debug configuration is too slow for you?  People who want to
debug C++ generally turn optimizations off, but for front-end devs, I
think building with --enable-debug and --enable-optimize should give you
an optimized build with the debug facilities turned on, which should be
much faster.  Although it is not going to be as fast as a
--disable-debug --enable-optimize build, there's a lot of value in
Mozilla developers running builds with debug checks turned on, so that
we can get good bug reports when an assertion fires when working on a
front-end feature, etc.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

2016-09-22 Thread Benjamin Smedberg 
Definitely explore this!

I want us to be very careful/deliberate about the privacy consequences of
this, though. Any values which could be user data need to be tightly
controlled, in the same manner we control access to the minidumps
themselves. So I don't think we should be too generic about this.

As data steward I'd like to be kept in the loop and do a data review of any
changes here.

--BDS

On Thu, Sep 22, 2016 at 9:28 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> On 09/22/2016 04:28 AM, Nicholas Nethercote wrote:
>
>> I want to highlight a nice case where converting a normal assertion
>> into a release assertion was a win. In bug 1159244 Michael Layzell did
>> this in nsTArray::ElementAt(), to implement a form of always-on array
>> bounds checking. See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
>> discussion of how this is finding real bugs in the wild. (As well as
>> identifying new bugs, it's also helping understand existing crash
>> reports, e.g. see bug 1291082 where the crash signature changed.)
>>
>
> Independently of the release/debug assertion, I want to raise something
> that I see in the patch above, and in a patch made to investigate some rare
> crashes in the JS engine.
>
> The patch from the bug above adds instrumentation to attach a dynamically
> computed reason string (snprintf).  In the JS engine Jan De Mooij did
> something similar by dumping content on the stack between 2 magic numbers,
> in order to include this information in crash reports.
>
> What I see is a recurring pattern where the classical MOZ_CRASH /
> MOZ_ASSERT might not be ergonomic enough.  I think we should add a way to
> annotate our crashes (even in debug builds) with some state, without going
> in the internals of MOZ_CRASHs or requiring privileged access to the
> mini-dump. Maybe something like:
>
>   MOZ_ASSERT(foo < 0x1000, MOZ_REASON("Unexpected value: %x", foo));
>
> which could be converted into a lambda doing the snprintf into a
> pre-reserved space.
>
> --
> Nicolas B. Pierron
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Buildbot Try artifact expiration

2016-09-22 Thread garndt 
In May it was decided that artifacts for try jobs running in TaskCluster should 
expire after 14 days.  This has greatly reduced the amount of try artifacts 
that we keep within s3 and we are looking to make the same changes to buildbot 
try artifacts that were uploaded using TaskCluster.

Bug 1303214 has been created to make this the new default when using mozharness 
to upload artifacts.  In the meantime the TaskCluster team would like to move 
forward with retroactively expiring buildbot try artifacts within S3 that are 
older than 14 days.

Note: this is only for Try artifacts that were created and uploaded using 
mozharness and stored within TaskCluster (but are actually buildbot jobs).

Ideally we should be able to keep default expiration times for Try artifacts 
consistent between buildbot and TaskCluster and so far we have found 14 days to 
be an acceptable default.

Please let me know if you see an issue with this and we can discuss.  A final 
notice will be sent prior to forced expiration if there are no objections.

-Greg
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

2016-09-22 Thread Nicolas B. Pierron 

On 09/22/2016 04:28 AM, Nicholas Nethercote wrote:

I want to highlight a nice case where converting a normal assertion
into a release assertion was a win. In bug 1159244 Michael Layzell did
this in nsTArray::ElementAt(), to implement a form of always-on array
bounds checking. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
discussion of how this is finding real bugs in the wild. (As well as
identifying new bugs, it's also helping understand existing crash
reports, e.g. see bug 1291082 where the crash signature changed.)


Independently of the release/debug assertion, I want to raise something that 
I see in the patch above, and in a patch made to investigate some rare 
crashes in the JS engine.


The patch from the bug above adds instrumentation to attach a dynamically 
computed reason string (snprintf).  In the JS engine Jan De Mooij did 
something similar by dumping content on the stack between 2 magic numbers, 
in order to include this information in crash reports.


What I see is a recurring pattern where the classical MOZ_CRASH / MOZ_ASSERT 
might not be ergonomic enough.  I think we should add a way to annotate our 
crashes (even in debug builds) with some state, without going in the 
internals of MOZ_CRASHs or requiring privileged access to the mini-dump. 
Maybe something like:


  MOZ_ASSERT(foo < 0x1000, MOZ_REASON("Unexpected value: %x", foo));

which could be converted into a lambda doing the snprintf into a 
pre-reserved space.


--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

2016-09-22 Thread Gijs Kruitbosch 

On 22/09/2016 05:28, Nicholas Nethercote wrote:

Greetings,

Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.

Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.

I want to highlight a nice case where converting a normal assertion
into a release assertion was a win. In bug 1159244 Michael Layzell did
this in nsTArray::ElementAt(), to implement a form of always-on array
bounds checking. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
discussion of how this is finding real bugs in the wild. (As well as
identifying new bugs, it's also helping understand existing crash
reports, e.g. see bug 1291082 where the crash signature changed.)

Obviously we can't convert every normal assertion in the codebase into
a release assertion. But it might be worth thinking about which normal
assertions are good candidates for conversion. Good candidates include
any assertion where the consequence of failure is dangerous, e.g.
might cause memory access violations.

Nick


Yes please. This + diagnostic assert also helps frontend people who 
build and run opt builds (because debug builds are too slow to be 
usable, especially when combined with the browser toolbox (JS 
debugging)). Right now I miss some of these and then only find out when 
the tests that I did run go orange on try and/or inbound/autoland, and 
then I have to locally change the relevant C++ so I can test in my opt 
build (or resign myself to doing a separate clobber debug build somewhere).


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

2016-09-22 Thread Wayne 

On 9/22/2016 12:28 AM, Nicholas Nethercote wrote:

Greetings,

Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.

Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.

I want to highlight a nice case where converting a normal assertion
into a release assertion was a win. In bug 1159244 Michael Layzell did
this in nsTArray::ElementAt(), to implement a form of always-on array
bounds checking. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
discussion of how this is finding real bugs in the wild. (As well as
identifying new bugs, it's also helping understand existing crash
reports, e.g. see bug 1291082 where the crash signature changed.)

Obviously we can't convert every normal assertion in the codebase into
a release assertion. But it might be worth thinking about which normal
assertions are good candidates for conversion. Good candidates include
any assertion where the consequence of failure is dangerous, e.g.
might cause memory access violations.

Nick


For grins I ran the socorro query from the bug report against 
Thunderbird 
https://crash-stats.mozilla.com/search/?moz_crash_reason=~ElementAt=Thunderbird&_sort=-date&_facets=signature&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION

2016-09-22 Thread Gerald Squelart 
On Thursday, September 22, 2016 at 5:58:58 PM UTC+10, Paul Adenot wrote:
> On Thu, Sep 22, 2016, at 07:33 AM, Gerald Squelart wrote:
> > Sitting on the shoulders of giants, an idea, in the unlikely case it's
> > not been thought of yet:
> > How about an assertion that files a crash report (or something lighter
> > like a telemetry blip) but does not actually crash?
> 
> I think you can do that with telemetry, we do that, for example, when we
> encounter a severe failure when trying to open audio devices [0], trying
> to get a sense of how frequent it is in the field.
> 
> Cheer,
> Paul.
> 
> [0]:
> http://searchfox.org/mozilla-central/source/dom/media/GraphDriver.cpp#595

Nice one Paul.

But I was hoping for something easier and more flexible than telemetry, where I 
can just write an assertion, and something will land in Socorro when it fails, 
but without crashing Firefox.

Cheers,
Gerald
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

2016-09-22 Thread Mark Banner 

On 22/09/2016 08:44, ISHIKAWA,chiaki wrote:

3:07:56 INFO -  1474488476446addons.xpi-utilsWARN
addMetadata: Add-on specialpow...@mozilla.org is invalid: Error: Invalid
addon ID: expected addon ID specialpow...@mozilla.org, found
special-pow...@mozilla.org in manifest  ...


I am not sure if this comes from the intended test.
Rather it looks a configuration error.
The error line seems to appear at beginning of the selected run of each
test directory.


...

cf. 3 results from the comm-central tree:
mozilla/testing/specialpowers/Makefile.in
♢7 XPI_PKGNAME = specialpow...@mozilla.org


Looks like this is different from what is specified in 
testing/specialpowers/install.rdf - which is the dashed version, and was 
introduced when it was rewritten last year.


The simplest thing is probably to change the install.rdf to remove the 
dash as then it wouldn't be changing the file name on disk - and also 
update the other couple of instances in the tree. Probably worth a 
running through a few tests on try just to make sure as well.


The test infrastructure has probably got away with it due to the next 
warning of "Could not uninstall invalid item from locked install 
location", so it kept on using it.


Mark
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION

2016-09-22 Thread Paul Adenot 
On Thu, Sep 22, 2016, at 07:33 AM, Gerald Squelart wrote:
> Sitting on the shoulders of giants, an idea, in the unlikely case it's
> not been thought of yet:
> How about an assertion that files a crash report (or something lighter
> like a telemetry blip) but does not actually crash?

I think you can do that with telemetry, we do that, for example, when we
encounter a severe failure when trying to open audio devices [0], trying
to get a sense of how frequent it is in the field.

Cheer,
Paul.

[0]:
http://searchfox.org/mozilla-central/source/dom/media/GraphDriver.cpp#595
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Converting assertions into release assertions

2016-09-22 Thread Patrick McManus 
+1 on MOZ_DIAGNOSTIC_ASSERT - its been very useful to me as well.

On Thu, Sep 22, 2016 at 6:40 AM, Bobby Holley  wrote:

> There's also MOZ_DIAGNOSTIC_ASSERT, which is fatal in pre-release builds
> but not release ones. It can be a good compromise to find bugs in the wild
> when the performance cost is probably negligible but you're still not quite
> comfortable shipping it on release. I added it last year while working on
> stability for the media stack, and found it very useful.
>
> bholley
>
> On Wed, Sep 21, 2016 at 9:28 PM, Nicholas Nethercote <
> n.netherc...@gmail.com
> > wrote:
>
> > Greetings,
> >
> > Assertions, such as MOZ_ASSERT, are great. But they only run in debug
> > builds.
> >
> > Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
> >
> > I want to highlight a nice case where converting a normal assertion
> > into a release assertion was a win. In bug 1159244 Michael Layzell did
> > this in nsTArray::ElementAt(), to implement a form of always-on array
> > bounds checking. See
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
> > discussion of how this is finding real bugs in the wild. (As well as
> > identifying new bugs, it's also helping understand existing crash
> > reports, e.g. see bug 1291082 where the crash signature changed.)
> >
> > Obviously we can't convert every normal assertion in the codebase into
> > a release assertion. But it might be worth thinking about which normal
> > assertions are good candidates for conversion. Good candidates include
> > any assertion where the consequence of failure is dangerous, e.g.
> > might cause memory access violations.
> >
> > Nick
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

2016-09-22 Thread ISHIKAWA,chiaki 

While perusing error log of try-comm-central run of
Windows 7 debug version run of |make mozmill| test on try-comm-central 
treeherder, I noticed a strange error message.


3:07:56 INFO -  1474488476446	addons.xpi-utils	WARN	addMetadata: 
Add-on specialpow...@mozilla.org is invalid: Error: Invalid addon ID: 
expected addon ID specialpow...@mozilla.org, found 
special-pow...@mozilla.org in manifest  ...



I am not sure if this comes from the intended test.
Rather it looks a configuration error.
The error line seems to appear at beginning of the selected run of each 
test directory.


The error lines surrounding the "special-pow...@mozilla.org in manifest" 
are as follows.

I quote  from one instance of such error lines.


13:07:52 INFO - 
['C:\\slave\\test\\build\\venv\\Scripts\\python.exe', 'runtest.py', 
'-t', 'keyboard', '--binary', 
'C:\\slave\\test\\build\\application\\thunderbird\\thunderbird.exe', 
'--symbols-path', 'C:\\slave\\test\\build\\symbols', '--plugins-path', 
'C:\\slave\\test\\build\\application\\thunderbird\\plugins', 
'--testing-modules-dir', 'C:\\slave\\test\\build\\test\\modules']
13:07:54 INFO -  Using profile dir: 
C:\slave\test\build\tests\mozmill\mozmillprofile
13:07:54 INFO -  [1244] WARNING: Failed to load startupcache file 
correctly, removing!: file 
c:/builds/moz2_slave/tb-try-c-cen-w32-d-000/build/mozilla/startupcache/StartupCache.cpp, 
line 219
13:07:54 INFO -  (debug) 
nsWindowWatcher::SetWindowCreator(nsIWindowCreator* aCreator) called
13:07:54 INFO -  [1244] WARNING: CheckLinkStatus called on main 
thread! No check performed. Assuming link is up, status is unknown.: 
file 
c:/builds/moz2_slave/tb-try-c-cen-w32-d-000/build/mozilla/netwerk/system/win32/nsNotifyAddrListener.cpp, 
line 707
13:07:54 INFO -  [1244] WARNING: This method is lossy. Use 
GetCanonicalPath !: file 
c:/builds/moz2_slave/tb-try-c-cen-w32-d-000/build/mozilla/xpcom/io/nsLocalFileWin.cpp, 
line 3477
13:07:56 INFO -  1474488476446	addons.xpi-utils	WARN	addMetadata: 
Add-on specialpow...@mozilla.org is invalid: Error: Invalid addon ID: 
expected addon ID specialpow...@mozilla.org, found 
special-pow...@mozilla.org in manifest 
(resource://gre/modules/addons/XPIProvider.jsm -> 
resource://gre/modules/addons/XPIProviderUtils.js:1658:15) JS Stack 
trace: addmetad...@xpiproviderutils.js:1658:15 < 
processfilechan...@xpiproviderutils.js:2018:23 < 
this.xpiprovider.checkforchan...@xpiprovider.jsm:3808:34 < 
this.xpiprovider.star...@xpiprovider.jsm:2794:25 < 
callprovi...@addonmanager.jsm:236:12 < 
_startprovi...@addonmanager.jsm:789:5 < 
addonmanagerinternal.star...@addonmanager.jsm:973:9 < 
this.addonmanagerprivate.star...@addonmanager.jsm:3017:5 < 
ammanager.prototype.obse...@addonmanager.js:71:9
13:07:56 INFO -  1474488476452	addons.xpi-utils	WARN	Could not 
uninstall invalid item from locked install location
13:07:57 INFO -  [1244] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed 
with result 0x80520012: file 
c:/builds/moz2_slave/tb-try-c-cen-w32-d-000/build/mozilla/extensions/cookie/nsPermissionManager.cpp, 
line 2675
13:07:57 INFO -  [calBackendLoader] Using icaljs backend at 
C:\slave\test\build\application\thunderbird\extensions\{e2fda1a4-762b-4020-b5ad-a41df1933103}\components\icaljs-manifest
13:07:57 INFO -  [1244] WARNING: 'NS_FAILED(rv)', file 
c:/builds/moz2_slave/tb-try-c-cen-w32-d-000/build/mozilla/dom/plugins/base/nsPluginHost.cpp, 
line 2364


OBSERVATION:
As it turns out, try-comm-central log for mozmill run of linux64 debug 
version also has a similar error.

So it is not windows specific.

*HOWEVER*, I don't see a similar error line on my local PC's test log.
I am testing linux64 debug version on local PC.

Something is incorrectly set up on try-comm-central?

Using DXR, I found 8 occurrences of special-pow...@mozilla.org, and
three occurrences of specialpow...@mozilla.org.

I suspect they should be consistently named.

TIA
cf. 3 results from the comm-central tree:
mozilla/testing/specialpowers/Makefile.in
♢7 XPI_PKGNAME = specialpow...@mozilla.org

mozilla/testing/testsuite-targets.mk
♢ 356 specialpow...@mozilla.org.xpi \

obj-x86_64-pc-linux-gnu/testing/specialpowers/Makefile
♢ 15 XPI_PKGNAME = specialpow...@mozilla.org


windows debug version raw log is:
https://archive.mozilla.org/pub/thunderbird/try-builds/ishik...@yk.rim.or.jp-8fa70f3401d6/try-comm-central-win32-debug/try-comm-central_win7_ix-debug_test-mozmill-bm126-tests1-windows-build3.txt.gz

https://treeherder.mozilla.org/logviewer.html#?job_id=21663=try-comm-central
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform