Re: Audit your code if you use mozilla::WeakPtr

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(); *

Re: Audit your code if you use mozilla::WeakPtr

and the ref blows up ... if (object) { object-Method(); // oops } - Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: David Major dma...@mozilla.com Cc: dev-platform@lists.mozilla.org Sent: Tuesday, October 8, 2013 4:27:03 PM Subject: Re: Audit your code if you use mozilla

Re: Reacting more strongly to low-memory situations in Firefox 25

It seems that the 12MB reservation was aborting due to an invalid parameter. I've filed bug 943051. - Original Message - From: Benjamin Smedberg benja...@smedbergs.us To: Ehsan Akhgari ehsan.akhg...@gmail.com, dev-platform@lists.mozilla.org Sent: Monday, November 25, 2013 9:18:02 AM

Re: People building and debugging Firefox on Windows wanted

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

Switching to Visual Studio 2013

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

Re: Switching to Visual Studio 2013

Please open bugs for this kind of thing. I filed 1061339 for you. - Original Message - From: xunxun xunxun1...@gmail.com To: David Major dma...@mozilla.com Cc: dev-platform@lists.mozilla.org, firefox-...@mozilla.org Sent: Monday, September 1, 2014 9:01:19 PM Subject: Re: Switching

Re: Switching to Visual Studio 2013

. David - Original Message - From: David Major dma...@mozilla.com 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 Visual Studio 2013

Re: Switching to Visual Studio 2013

- From: David Major dma...@mozilla.com 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. The build machines needed a reinstall of VS2013 due

Re: Compiler version expectations

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:

Re: Using __declspec(thread) on Windows

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

Re: About the bitfield requirement for portibility

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 quanxunz...@gmail.com To:

Re: Shutdown hangs are very common

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

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

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 wrote:

Re: Changing the representation of rectangles in platform code

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

Re: Key measurements from memory reports are now shown by crash-stats.m.o

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

Re: Should &&/|| really be at the end of lines?

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

Re: Please do not add any new CppUnitTests/GeckoCppUnitTests

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

Re: windows build anti-virus exclusion list?

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

Re: A reminder about commit messages: they should be useful

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

Renaming nsAString_internal to nsAString

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

Re: Care in the use of MOZ_CRASH_UNSAFE_* macros: data review needed

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? >

Re: Actually-Infallible Fallible Allocations

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,

Gecko Profiler Win64 stability

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

Re: Improving visibility of compiler warnings

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

Re: C++ function that the optimizer won't eliminate

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

Re: C++ function that the optimizer won't eliminate

> On Fri, Oct 6, 2017 at 5:41 PM, David Major <dma...@mozilla.com> 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

Re: Pulsebot in #developers

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

Visual Studio 2017 coming soon

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:

Re: Visual Studio 2017 coming soon

, and easily testable on Try. Thank you! On Wed, Oct 25, 2017 at 5:48 PM, David Major <dma...@mozilla.com> 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

Re: Update on rustc/clang goodness

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

Windows Address Sanitizer enabled on trunk

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

Re: Windows Address Sanitizer enabled on trunk

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 > introd

Re: Firefox 60 Beta build error on ARM

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

Re: Visual Studio 2017 coming soon

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

Re: Visual Studio 2017 coming soon

), 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 <sle...@mozilla.com> wrote: > Hello, > > > On 25/10/2017 23:48, David Major wrote: > > I'm planning to move p

Re: Using clang-cl to ship Windows builds

=5336df94a9ce=1 To call out a few: Speedometer scores increased by 6% on Win64 and 12% on Win32, and the most dramatic improvement was displaylist_mutate at 27%! As far as I'm aware, no blockers have come up and clang-cl is still looking good for the 63 train. On Tue, Jul 10, 2018 at 4:29 PM David

Local Windows builds to use clang-cl by default

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

Re: Using clang-cl to ship Windows builds

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 official Win

Using clang-cl to ship Windows builds

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

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

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

Please try out clang-cl and lld-link on Windows

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

Re: Please try out clang-cl and lld-link on Windows

t; don't work with 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,

Re: Pointer to the stack limit

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 --

PSA: Inadvertently exporting third-party symbols

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

Re: PSA: Min clang / libclang requirement was updated not long ago...

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

Re: PSA: Min clang / libclang requirement was updated not long ago...

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

Re: Improving our usage of Bugzilla

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

Re: Moving reviews to Phabricator

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

Re: Type-based alias analysis and Gecko C++

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

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

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

Re: Faster compilers available in bootstrap

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

Faster compilers available in bootstrap

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

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

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