Is there a specific problem that's being solved by this proposal? It would
be helpful to make this a bit more concrete, like "these benchmarks go x%
faster", or "here's a list of overflow bugs that will just vanish", or
"here's some upcoming work that this would facilitate".
On Thu, Feb 9, 2017 at
Nice!
I see that these fields are available in Super Search already, which is
great. This is going to make search queries really powerful.
On Tue, Feb 14, 2017, at 12:37 PM, Nicholas Nethercote wrote:
> Hi,
>
> For a long time we have collected a memory report for most crash reports
> where the
One thing I like about trailing operators is that they tend to match
what you'd find in bullet-point prose. Here's a made-up example:
You can apply for a refund of your travel insurance policy if:
* You cancel within 7 days of purchase, and
* You have not yet begun your journey, and
* You have not
TL;DR this will change crash signatures and possibly other tool output;
talk to me if this adversely affects you.
Now that bug 1332639 has removed the external string API, we no longer need
to differentiate between internal and external strings.
Currently we #define nsAString to nsAString_interna
Try using Sysinternals Process Monitor to see what files MsMpEng.exe is
reading.
On Fri, Mar 17, 2017, at 04:26 PM, Ben Kelly wrote:
> Hi all,
>
> I'm trying to configure my new windows build machine and noticed that
> builds were still somewhat slow. I did:
>
> 1) Put it in high performance po
I'd like to add to this a reminder that commit messages should describe
the _change_ and not the _symptom_. In other words, "Bug XYZ: Crash at
Foo::Bar" is not a good summary.
This is implied by what Boris said, but I've seen enough of these on my
pulsebot backscroll that it's worth mentioning exp
Hi,
The Gecko Profiler used to be notoriously unstable on 64-bit Windows. (If
you're curious: it's mostly because the unwinding rules for Win64 require
the system libraries to do a lot of synchronization, which our stack walker
would often call in ways that could deadlock.)
Ever since the last Qu
I'm not sure if this is exactly the same as the ALLOW_COMPILER_WARNINGS
that we use for warnings-on-errors, but FWIW as of a couple of months
ago I cleaned out the last warning-allowance in our "own" code.
ALLOW_COMPILER_WARNINGS usage is now only in external libraries (I'm
counting NSS and NSPR as
As of bug 1275780, rust panic text gets reported as a MOZ_CRASH reason.
On Mon, Jul 17, 2017 at 12:42 PM, Benjamin Smedberg
wrote:
> I don't know really anything about how rust panics get reflected into
> crash-data. Who would be the right person to talk to about that?
>
> --BDS
>
> On Mon, Jul
I don't think that anyone deliberately set out to write the code this way.
Likely this is fallout from the mass-refactorings in bug 968520 and related
bugs. I'd recommend working with poiru and froydnj to see if there's any
automated follow-up we could do to remove/improve this pattern.
On Tue, Au
I bet Google Benchmark will have what you want.
As a first guess, maybe this?
https://github.com/google/benchmark/blob/master/include/benchmark/benchmark.h#L297
(And if godbolt says they are wrong, please send them a PR :))
On Fri, Oct 6, 2017 at 9:16 AM, Gabriele Svelto wrote:
> On 06/10/201
> On Fri, Oct 6, 2017 at 5:41 PM, David Major wrote:
> > I bet Google Benchmark will have what you want.
> >
> > As a first guess, maybe this?
> > https://github.com/google/benchmark/blob/master/include/
> benchmark/benchmark.h#L297
>
> Thank you. I guess i
I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.
VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
improvement on Speedometer. There is also increased support for C++14 and
C++17 language features:
https://docs.microsoft.com/en-us/cpp/visua
Agreed, changing compilers of an already-released ESR isn't a good idea.
You could use 2017 to build ESR52 locally though, if that's what you're
asking. Our tree has supported 2017 builds for a good while, since it's the
default VS download from Microsoft and a number of Mozillians have been
using
), I'm
comfortable with that number. If it goes longer than that, I agree it makes
sense to wait for a new train.
On Thu, Oct 26, 2017 at 3:31 AM, Sylvestre Ledru wrote:
> Hello,
>
>
> On 25/10/2017 23:48, David Major wrote:
> > I'm planning to move production Windows
rvice, and easily testable on Try. Thank you!
On Wed, Oct 25, 2017 at 5:48 PM, David Major wrote:
> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
>
> VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
> improv
I use #developers for two things:
1. I prefer to keep my discussions in smaller topic channels, but for my
sanity I also try to keep my channel list small. There is a large set of
people whom I ping roughly once a month and can't be bothered matching
channels with. #developers is my "lowest common
Link xul.dll in 20 seconds with this one weird trick!
Hi everyone,
clang-cl builds of Firefox have come a long way, from being a hobby project
of a few developers to running static analysis in CI for more than a year
now. The tools are in really good shape and should be ready for broader use
wit
SDK version 10.0.16299.0 and later..."
>
> I know that I can set WINDOWSSDKDIR, but I'm not willing to mess too
> much with the env. Is there a bug tracking the update to the latest
> sdk, or automatically use the right one, that I can follow?
>
>
> On Tue, Mar 13, 20
This sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=1434589
which currently doesn't have a fix. You might be able to work around
it for now with --disable-webrtc.
On Wed, May 2, 2018 at 1:08 PM, Charles G Robertson
wrote:
> Hi,
>
> I'm trying to build Firefox 60 Beta on Arm64 and seeing
We've confirmed that this issue with debug symbols comes from lld-link and
not from clang-cl. This will likely need a fix from the LLVM side, but in
the meantime I'd like to encourage people not to be deterred from using
clang-cl as your compiler.
On Thu, May 10, 2018 at 9:12 PM Xidorn Quan wrote
Bug 1360120 on inbound enables Windows ASan builds and tests on trunk branches.
Initially these are tier-2 while we confirm that this doesn't
introduce test flakiness. If nothing catches fire, I intend to bump
them to tier-1 in the near future.
You can run these jobs on try under the platform nam
As of bug 1467126 these jobs are now running at tier 1.
On Fri, Jun 1, 2018 at 3:16 PM David Major wrote:
>
> Bug 1360120 on inbound enables Windows ASan builds and tests on trunk
> branches.
>
> Initially these are tier-2 while we confirm that this doesn't
> intro
Bug 1443590 is switching our official Windows builds to use clang-cl
as the compiler.
Please keep an eye out for regressions and file a blocking bug for
anything that might be fallout from this change. I'm especially
interested in hearing about the quality of the debugging experience.
It's possib
nt us from collecting data on Nightly.
On Tue, Jul 10, 2018 at 4:31 PM Chris Peterson wrote:
>
> How does the performance of clang-cl builds compare to MSVC builds on
> benchmarks like Speedometer?
>
>
> On 2018-07-10 1:29 PM, David Major wrote:
> > Bug 1443590 is switching our of
This touches on a really important point: we're not the only ones
allocating memory.
Just a few that come to mind: GPU drivers, system media codecs, a11y
tools, and especially on Windows we have to deal with "utility"
applications, corporate-mandated gunk, and downright crapware.
When we're measu
On Wed, Nov 9, 2016, at 06:17 PM, Mike Hommey wrote:
> On Thu, Nov 10, 2016 at 11:04:05AM +1100, Nicholas Nethercote wrote:
> > On Thu, Nov 10, 2016 at 10:00 AM, Mike Hommey wrote:
> >
> > >
> > > CppUnitTests are fine to keep.
> >
> >
> > Having said that, IMO it is desirable to convert CppUni
Isn't it ultimately up to the developer to get it right? Someone could just as
well forget to use |if (object)| from your example.
Here's a sample usage from the header file:
* // Test a weak pointer for validity before using it.
* if (weak) {
* weak->num = 17;
* weak->act();
*
of stuff happens and the ref blows up ...
if (object) {
object->Method(); // oops
}
- Original Message -
From: "Ehsan Akhgari"
To: "David Major"
Cc: dev-platform@lists.mozilla.org
Sent: Tuesday, October 8, 2013 4:27:03 PM
Subject: Re: Audit your code if you use mo
It seems that the 12MB reservation was aborting due to an invalid parameter.
I've filed bug 943051.
- Original Message -
From: "Benjamin Smedberg"
To: "Ehsan Akhgari" , dev-platform@lists.mozilla.org
Sent: Monday, November 25, 2013 9:18:02 AM
Subject: Re: Reacting more strongly to low-me
My improvements were closer to 5%. I use VS2013's amd64_x86 cross-compiler. I
didn't touch the -FS flag (I imagine it just becomes meaningless).
Debug build, before: build 17:06, objdir 3.83GB
Debug build, -Z7:build 16:06, objdir 5.22GB
Opt build, before: build 17:47, objdir 3.01GB
Opt buil
We plan to switch the Windows build machines to Visual Studio 2013 on the
Firefox 35 train.
Some benefits from this change:
* No more linker OOM crashes. VS2013 includes a 64-bit toolchain for 32-bit
builds, so the linker will no longer be limited to 4GB address space.
* The linker capacity open
Please open bugs for this kind of thing. I filed 1061339 for you.
- Original Message -
> From: "xunxun"
> To: "David Major"
> Cc: dev-platform@lists.mozilla.org, firefox-...@mozilla.org
> Sent: Monday, September 1, 2014 9:01:19 PM
> Subject: Re: Switc
he process.
David
- Original Message -
> From: "David Major"
> To: dev-platform@lists.mozilla.org, firefox-...@mozilla.org
> Sent: Friday, August 22, 2014 6:27:58 PM
> Subject: Switching to Visual Studio 2013
>
> We plan to switch the Windows build machines to
David
- Original Message -
> From: "David Major"
> To: dev-platform@lists.mozilla.org, firefox-...@mozilla.org
> Sent: Wednesday, October 8, 2014 7:21:07 PM
> Subject: Re: Switching to Visual Studio 2013
>
> Update: the switch will happen early in version 36.
>
I was thinking it would be nice to support VS2010 as long as any of our main
channels use it -- meaning we could drop it on the first day of 39. But I have
no practical justification for that. If it causes a burden on Skia work then it
might be reasonable to switch sooner.
> This set: http://ch
> in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in
> our shipped Windows builds mozglue.dll is statically linked to firefox.exe
> so we could put __declspec(thread) variables there.
What does 'statically linked' mean in this context? Mozglue.dll is still a DLL,
but yes
Mixing types will likely produce unexpected and/or wasteful results. Examples
at
http://randomascii.wordpress.com/2010/06/06/bit-field-packing-with-visual-c/. I
believe that is still true in VS2013.
David
- Original Message -
> From: "Xidorn Quan"
> To: dev-platform@lists.mozilla.org
> Should fixing shutdown hangs be higher priority?
> And if so, should we allow features with shutdown hangs to be released?
I admit to skimming over shutdown-hang signatures when looking at
topcrash lists. In my experience they're often longstanding issues that
are difficult to diagnose and rare
May I request that the major parts of this not happen until we have a
blame that can "see through" such changes.
Last I checked, gps had some ideas in that space but lacked time to
implement.
On Wed, Jul 15, 2015, at 03:23 AM, Benjamin Smedberg wrote:
>
>
> On 7/8/2015 7:31 AM, Nathan Froyd wro
Hi,
Local Windows builds will use clang-cl and lld-link by default as of
bug 1483835. This will make your builds match what has been shipping
on Nightly for the last several weeks, and help avoid the occasional
MSVC bustage that sneaks in now that those builds are tier-2.
If you already ran `mach
looking good for the 63 train.
On Tue, Jul 10, 2018 at 4:29 PM David Major wrote:
>
> Bug 1443590 is switching our official Windows builds to use clang-cl
> as the compiler.
>
> Please keep an eye out for regressions and file a blocking bug for
> anything that might be f
You'll need platform-specific code, but on Windows there's
https://searchfox.org/mozilla-central/rev/13788edbabb04d004e4a1ceff41d4de68a8320a2/js/xpconnect/src/XPCJSContext.cpp#986.
And, to get a sense of caution, have a look at the ifdef madness surrounding
the caller --
https://searchfox.org/m
Hi,
As importing third-party code into libxul seems to be pretty popular,
I wanted to point out something that's easy to overlook.
Libraries usually have code that goes like:
#ifdef _WIN32
#define MYLIB_EXPORT __declspec(dllexport)
#else
#define MYLIB_EXPORT __attribute__((visibility("default"))
For what it's worth, arcanist works fine for me in WSL, with a
considerably less-horrifying installation process than on real
Windows.
With an alias you can call it from MozillaBuild as if it were native:
alias arc="cmd //c ubuntu1804 run arc"
On Wed, Feb 6, 2019 at 3:49 PM Jörg Knobloch wrote:
I don't think anyone wants to allow aliasing merely for its own sake.
A lot of these flags were added just to keep builds working in the
face of noisy compilers a long time ago. It would be good to retest
with our current codebase and current compilers and see where we
stand. If we can easily remov
Does configure warn about this?
The link between this error and needing to bootstrap is not super
clear (and a surprising number of people don't read dev-platform) so
I'm not looking forward to answering the same question in #build for
the rest of the week. :)
On Tue, Feb 26, 2019 at 12:23 PM Emi
https://bugzil.la/bootstrap-toolchain-redownloads (it's even got a
name!) is a really annoying one that's been on file for 6+ months.
On Wed, Feb 27, 2019 at 8:39 AM Nathan Froyd wrote:
>
> On Wed, Feb 27, 2019 at 6:22 AM Kartikaya Gupta wrote:
> > On Wed, Feb 27, 2019 at 3:40 AM Axel Hecht wro
Will setting the "regressed by" field send mail to the subscribers of
the earlier bug? This was a useful aspect of the blocks/depends field.
On Tue, Mar 12, 2019 at 1:59 PM Sylvestre Ledru wrote:
>
> Le 12/03/2019 à 17:48, Andrew McCreight a écrit :
> > On Tue, Mar 12, 2019 at 3:55 AM Sylvestre L
On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley wrote:
>
> Thanks Mike!
>
> So Fennec is the last remaining non-e10s configuration we ship to users.
> Given that Fennec test coverage is somewhat incomplete, we probably want to
> keep running desktop 1proc tests until Fennec EOL. We don't strictly nee
As of bug 1326486, our clang toolchains for Linux and Windows are built
with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)
Under optimal conditions (Spidermonkey build, touch mfbt) I've seen 10-15%
compile time improvements locally, but in more common scenarios the gains
will be
Yes, I believe so.
On Thu, Apr 9, 2020 at 1:09 PM Botond Ballo wrote:
> Thanks, compile time improvements are always good news!
>
> Out of curiosity, does this impact builds targeting Android on Linux or
> Windows?
>
> Thanks,
> Botond
>
> On Thu, Apr 9, 2020 at
I agree that it's a bad idea for users to be running permanently with this
setting on their daily driver browsers.
But the environment variable has been a huge productivity enhancer to
reduce my mental load when setting up an extra-hairy debug session or
taking system traces.
I wish we could have
53 matches
Mail list logo
