In bug 1316755, I'm working on removing support for the IPDL keywords
spawns, opens and bridges. These have been superseded by endpoints, a more
general mechanism for starting up IPDL actors. The only drawback is that
endpoints don't allow for static analysis of the relationships between
processes,
Last I looked, we didn't have any tests for VRFrameData, FWIW (bug
1317258). I see some now under servo/ but presumably we don't run those.
Maybe I'm missing some.
It would also be good to make sure our internal fuzzers are fuzzing these
APIs to at least catch basic errors.
Andrew
On Wed, Mar 1,
On Fri, Mar 3, 2017 at 4:15 PM, Nicholas Nethercote
wrote:
> Hi,
>
> I want to understand all the different processes that we can and will have
> in Firefox. Here's a list I constructed off the top of my head.
>
> - main process
>
> - content process(es): 1 on release for most users; 2 on Nightly
On Mon, Mar 6, 2017 at 4:45 PM, Eric Rahm wrote:
> I'd suggest looking at the memory overhead of Chrome's individual processes
> as compared to ours, it's pretty impressive. My blog posts on our own e10s
> memory usage [1] and comparison to other browsers [2] have further details.
> I'm planning
On Thu, Mar 9, 2017 at 1:55 PM, Nicholas Alexander
wrote:
> On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky wrote:
>
> > On 3/9/17 4:35 PM, Eric Rescorla wrote:
> >
> >> I'm in favor of good commit messages, but I would note that current m-c
> >> convention really pushes against this, because peop
If you are seeing this error when you try to do |git mozreview push|,
update your version-control-tools. Then you'll see a different error. Work
related to that is being looked at in
https://bugzilla.mozilla.org/show_bug.cgi?id=1338530
Andrew
___
dev-pla
On Wed, Mar 22, 2017 at 6:00 PM, Nicholas Nethercote wrote:
> Do we have a clear definition of "content process"? I.e. does/will it
> include:
>
> - GMP processes (no?)
> - GPU process (probably not?)
> - file:// URL processes (probably should?)
> - Web Extensions processes (probably should?)
> -
Note: this only affects you if you write tests in the
ipc/ipdl/test/ipdl/error/ directory.
In bug 1319620, I added checking of expected failures for IPDL error unit
tests. This will ensure that changes like renaming IPDL keywords won't make
the error tests silently start failing for the wrong reas
I updated my tree this morning and did a build, and I ended up with a new
untracked
nsILayoutHistoryState.h file. Be sure to not accidentally commit it.
I deleted the file, and then had to do a clobber build to fix everything.
I filed bug 1351461 for the clobber issue or whatever it is.
_
This was posted on mozilla.tools yesterday but doesn't seem to have made it
to dev.platform. It is likely to be of interest to many people on this
list. Note the comment "If you have questions or concerns beyond those
addressed below, please
use the mozilla.tools group and/or #phabricator on IRC an
On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek wrote:
> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
> > Would it be possible to add a check like:
> > "You haven't updated your local configuration since XX days, please
> > consider running
> > mach bootstrap ?"
>
> We've had mach p
On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote wrote:
> There's also a pre-processor constant that we define in Valgrind/ASAN/etc.
> builds that you can check in order to free more stuff than you otherwise
> would. But I can't for the life of me remember what it's called :(
>
NS_FREE_PERMA
On Mon, May 22, 2017 at 4:45 PM, Karl Tomlinson wrote:
> Andrew McCreight writes:
>
> > On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote <
> n.netherc...@gmail.com
> >> wrote:
> >
> >> There's also a pre-processor constant that we define in
>
On Thu, May 25, 2017 at 4:03 PM, wrote:
> On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> > >> `mach build` attempts to parse compiler warnings to a persisted
> > >> "database.
Just use NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION instead.
These have been identical for years, so I just removed the _INHERITED
variant in an attempt to make the CC macros a little simpler to deal with,
in bug 1391005.
Andrew
___
dev-platform mailing li
On Thu, Sep 7, 2017 at 5:07 AM, Emilio Cobos Álvarez
wrote:
> Hi,
>
> I have a coding style question which I don't see addressed in the coding
> style page.
>
> Given there have been a few threads lately on coding style, I guess I
> should just ask.
>
> We have a lot of meaningless argument names
s
> only a getter", and "ReferenceError: assignment to undeclared variable",
> and if you see any, file bugs blocking bug 1394556.
>
> 2) Andrew McCreight has been working on changing the component loader to
> load most modules and components into a single global[3], with each
On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta wrote:
> I've tried using cinnabar a couple of times now and the last time I
> tried, this was the dealbreaker for me. My worfklow often involves
> moving a branch from one machine to another and the extra hassle that
> results from mismatched SHAs
On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla wrote:
> Generally no, but this is an unfortunate consequence of Mozilla's decision
> a while ago to pick a VCS which has not turned out to be the dominant
> choice (not placing blame here, but I think it's clear that's how it's
> turned out). The re
I half-heartedly keep an eye on intermittent leaks, so I can more active in
looking at them. We'll need more logging for them to be actionable, but I
guess the high frequency ones are easier to catch.
Andrew
On Thu, Oct 26, 2017 at 10:20 AM, Geoffrey Brown wrote:
> Some of our most troublesome
I just landed a patch for bug 1409115 that fixes a leak where a global data
structure (some per-process service worker queue) holds alive a DOM
promise, which ends up leaking the window forever. Fundamentally, holding
alive a DOM promise, which holds alive its window, from a data structure
that is
On Fri, Dec 15, 2017 at 9:38 AM, James Graham
wrote:
> Following the summary of what we achieved in wpt in the last year, I'd
> like to solicit input from the gecko community to inform the
> priorities of various pieces of wpt work for the next year.
>
> In order to maximise the compatibility ben
On Wed, Jan 10, 2018 at 6:22 AM, Romain Testard wrote:
> Some enterprises may indeed find that enabling site isolation is worth the
> trade-offs (memory usage seems to be the main one on Chrome's
> implemenation).
>
Just to be clear here, we do not support the same kind of site isolation
that Ch
Bug 767640 just merged to mozilla-central. This patch makes it so that Ci,
Cr, Cc, and Cu are automatically defined in any chrome scope that has a
Components object. Rejoice, because you no longer need to add "var Ci =
Components.interfaces" into every file.
I have a followup bug, bug 1432992, tha
Following up on my previous post, I have just landed (in bug 1432992) the
removal of most of the definitions of Ci, Cr, Cc, and Cu. This touched
almost 2000 files, so it may affect your patches, but hopefully rebasing is
easy. Thank you to Florian for reviewing a nearly-unreviewable patch and
sugg
I recently landed bug 1438688, which makes it so that we don't ship XPT
files any more, so they don't need to be added to a package-manifest.in
file. (Instead, the XPT information is compiled into the binary.) I think
it'll give you an error if you add it anyways, but I haven't tested it. We
still
On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch
wrote:
> Dumb question because I don't do this very often - sorry!
>
> I am intending to async-ify a sync JS-implemented idl-defined API (which
> currently returns an unsigned long), that has a few C++ consumers. I was
> thinking the simplest solu
A few years ago I came up with an approach for using a combination of cycle
collector logs and DMD (which tracks all live blocks of heap allocated
memory) to investigate leaks of refcounted objects. I've only had to use it
about a half dozen times (most recently in bug 1451985), but it is very
hand
For people who aren't subscribed to dev-firefox, be aware that open bugs
that haven't been modified in a year have been set to "inactive" without
any bugmail being generated, in bug 1445054. It is probably better to that
thread rather than creating a new parallel thread on this list...
Andrew
--
On Wed, Jul 11, 2018 at 5:42 AM, David Bruant wrote:
>
>
> * Andrew McCreight created a tool for tracking JS memory usage, and
>> figuring
>> out which scripts and objects are responsible for how much of it
>> (https://bugzil.la/1463569).
>>
> How often i
as dropped 1.1-1.9MB.
>>
>> Particular credit goes to:
>>
>> * Eric Rahm added an AWSY test suite to track base content process memory
>>(https://bugzil.la/1442361). Results:
>>
>> Resident unique: https://treeherder.mozilla.org
>> /perf.html#/graphs
On Sun, Jul 29, 2018 at 7:35 PM, Anthony Jones wrote:
> I'm chuffed to announce that Web Replay has finally made its way into
> nightly. It brings tardis like functionality (or perhaps rr like) to
> Firefox Devtools, enabling recording and replaying of tab behavior, and
> best of all, stepping ba
On Tue, Aug 4, 2015 at 9:33 AM, Jonas Sicking wrote:
> Fingerprinting doesn't seem useful if the fingerprint changes every
> few minutes as the battery level changes.
>
> I do agree that there are concerns that if the user has
> private-browsing pages and non-private-browsing pages open at the sa
Apparently Bugzilla 2fa breaks the weird cookie authentication method that
git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug,
but in the meanwhile I've been working on making git-bz-moz use the
Bugzilla backend of bexport, which is less hacky and supports using API
keys for
, Sep 15, 2015 at 2:37 PM, Andrew McCreight
wrote:
> Apparently Bugzilla 2fa breaks the weird cookie authentication method that
> git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug,
> but in the meanwhile I've been working on making git-bz-moz use the
&g
Sorry, the command is actually |git bz apply 12345| as you probably figured
out.
Andrew
On Tue, Sep 15, 2015 at 2:40 PM, Andrew McCreight
wrote:
> Oh, and another thing I meant to mention that seems underused: if you are
> using git-bz-moz, the |git apply| command is pretty handy. You
On Thu, Sep 17, 2015 at 6:50 AM, Ehsan Akhgari
wrote:
> git bz edit and git bz push don't work, but the rest should, so please file
>> issues at https://github.com/mozilla/git-bz-moz or email me if you notice
>> them. (Oh, I think setting reviewer flags for Firefox product bugs doesn't
>> work, i
On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart wrote:
> Good stuff!
>
> I hope you'll consider tracking AddRef's and Release's as well.
>
> I recently experimented with that for a troubled RefCounted class [1], and
> it was very useful to find which AddRef didn't have its corresponding
> Releas
On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight
wrote:
>
>
> On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart
> wrote:
>
>> Good stuff!
>>
>> I hope you'll consider tracking AddRef's and Release's as well.
>>
>> I recently experimen
[1]
[1]
https://groups.google.com/forum/#!topic/mozilla.dev.version-control/z9z9N7_vWiY
Andrew
On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight
wrote:
> Apparently Bugzilla 2fa breaks the weird cookie authentication method that
> git-bz-moz and bzexport use. I think I've read that
On Thu, Sep 24, 2015 at 4:23 PM, Nicholas Nethercote wrote:
> On Thu, Sep 24, 2015 at 2:29 PM, Ehsan Akhgari
> wrote:
> > On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:
> >>
> >> * Coverity, a proprietary tool with a great (but slow) web interface.
> >
> > Does anybody look at these regularly? I
49 PM, Andrew McCreight
wrote:
> I've updated my repository for my git-bz REST API branch:
> https://github.com/amccreight/git-bz-moz/tree/RestAPI
>
> I think everything is fixed now, so please try it out and let me know if
> you encounter problems or something seems slow. (There
I'd also note that Google at least used to ship a similar kind of thing to
their Canary users a few times a week, called SyzygyASAN:
http://blog.chromium.org/2013/05/testing-chromium-syzyasan-lightweight.html
I haven't found a ton of detail about whether they still do it but that
blog post does s
On Wed, Mar 9, 2016 at 12:17 PM, Boris Zbarsky wrote:
> Just to satisfy my curiosity, what is AFL?
>
AFL is American Fuzzy Lop, a fuzzer that uses a combination of compiled-in
code coverage and genetic algorithms. http://lcamtuf.coredump.cx/afl/ It
has found a ton of errors in all sorts of progr
On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:
> Bug 1243083 tracks enabling e10s by default when running tests locally.
> I intend to do this for as many harnesses as possible unless someone
> says otherwise.
Great!
[some text deleted]
One potential sti
chrome to help avoid this
> confusion?
>
>
>>
>> On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari
>> wrote:
>>
>>> On 2016-03-24 1:25 PM, Andrew McCreight wrote:
>>> > One potential sticking point is mochitest-chrome. It currently does not
>>
On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson
wrote:
> Anthony's Media Playback team has been using a simple and effective triage
> system without special tags. All open bugs in the Audio/Video Playback
> component are in one of four states at all times:
>
> * Priority P1 bugs should be fixed A
status that is just confusing to bug
reporters, which discourages people from filing more bugs.
Andrew
>
> —
> - Milan
>
>
>
> > On Apr 1, 2016, at 11:16 , Andrew McCreight
> wrote:
> >
> > On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson
> > wrot
Emma can correct me if I'm wrong, but I think she is using "Firefox" in the
non-jargony sense of the entire thing we're shipping in Firefox, including
Gecko. We've been using this system for a month or so in DOM. I think it
has been going well. Anybody who is interested can ask Andrew Overholt or I
Thank you for opening a discussion thread rather than posting more in the
bug.
On Mon, May 9, 2016 at 11:23 AM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:
> Hi!
>
> Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a
> OSS Project!
> The same mistake made Orac
On Fri, May 13, 2016 at 1:02 PM, wrote:
> Why do you developers keep insisting breathlessly that 64-bit builds are
> memory hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have
> a 4 GB laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think
> that I use Firefox close
On Thu, May 19, 2016 at 8:04 AM, Ben Kelly wrote:
> 3) Supports async pipe streams using a new PSendStream actor from
> *child-to-parent*. I have plans to add support for parent-to-child, but I
> don't have a consumer yet and we need to figure out some issues with
> PBackground targeting worker
On Thu, May 19, 2016 at 4:09 PM, Matthew N. wrote:
> As a reminder, the nice thing about pushPrefEnv is that the pref changes
> are reverted at the end of the test file which avoids them leaking into
> other tests unintentionally.
>
Another good thing about it is that set*Pref isn't actually syn
On Mon, May 30, 2016 at 11:22 PM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:
> 6 MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> collector found more references to an object than its refcount)509
> 0.04 %
>
That's bug 1266882.
15 MOZ_RELEASE_ASSERT(aRefCount !=
On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote wrote:
> If you use your favourite source code search tool to look for
> "Shutdown too long", you'll find that this crash is occurring in
> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
> DXR link:
>
Sure, you can indiv
On Fri, Jun 3, 2016 at 6:57 AM, Ted Mielczarek wrote:
> BugHunter[1] attempts to reproduce crashes from crash-stats by loading
> the URLs from the crash reports, which is sometimes successful.
>
Of note, BugHunter also uses both debug and AddressSanitizer builds, which
occasionally turns up some
blassey landed a patch to suggest that users submit unsubmitted crash
reports. This is going to make various kinds of crashes, like shutdown
crashes, grossly overrepresented in the crash-stats "Top Crashers" list.
You probably want to use "By build date" instead of the default "By report
date" for
On Wed, Jun 22, 2016 at 1:05 PM, Henri Sivonen wrote:
> Now that I'm looking at the hand-written notes that I made in the
> meeting, I notice that the above paragraph fails to say how the
> AddRef, Release and associated cycle collection-related calls are
> routed from C++ to Rust or from Rust to
On Thu, Jun 30, 2016 at 8:41 AM, Aaron Klotz wrote:
> Did the now-defunct exit(0) project ever come up in this discussion?
>
> See bugs 662444 and 826143. This was a perf team project back in the
> Snappy days where the objective was to write important data to disk ASAP,
> then exit(0) without do
On Sun, Jul 10, 2016 at 7:29 PM, Martin Thomson wrote:
> Is now the right time to start talking about retiring checkin-needed,
> or is it still heavily used?
>
It is useful for anybody who doesn't use MozReview. FWIW I see 14 bugs with
it set right now.
>
> On Sat, Jul 9, 2016 at 4:58 AM,
I'm not sure of the particulars, but I believe ccache doesn't share the
results between two object directories unless you set it up explicitly to
use relative paths. Or something like that.
https://ccache.samba.org/manual.html#_compiling_in_different_directories
On Fri, Aug 19, 2016 at 3:45 PM,
We regularly run AddressSanitizer and Valgrind on mozilla-central, so it
seems likely this is Thunderbird specific. Please file security bugs in
bugzilla with any reports you have found.
Andrew
On Thu, Aug 25, 2016 at 10:59 AM, ISHIKAWA,chiaki
wrote:
> Hi,
>
> I occasionally check C-C TB by run
Searchfox works pretty well for blame including the CVS history, including
large files that github won't show you.
On Thu, Aug 25, 2016 at 12:09 PM, Philip Chee wrote:
> On 16/09/2015 01:01, smaug wrote:
> > On 09/15/2015 06:53 PM, Boris Zbarsky wrote:
> >> On 9/15/15 11:11 AM, Ben Hearsum wrote
On Fri, Aug 26, 2016 at 8:16 PM, Gregory Szorc wrote:
> What I'm trying to say is thank you for reminding me to implement the
> hook. And congratulations on likely being the last person to perform a case
> only rename on the repo.
>
Sarcastic commentary on an innocent mistake is not helpful.
In DOM triage, we've just set up our list to not include bugs with the
keyword intermittent failure. Ideally, we'd see intermittent failures that
have a high rate, but given that sheriffs keep an eye on oranges, they can
look for somebody to fix frequent ones as needed.
On Fri, Sep 2, 2016 at 11:4
On Fri, Sep 2, 2016 at 12:11 PM, Ryan VanderMeulen wrote:
> On 9/2/2016 2:56 PM, Andrew McCreight wrote:
>
>> In DOM triage, we've just set up our list to not include bugs with the
>> keyword intermittent failure. Ideally, we'd see intermittent failures that
>>
You could also just file things like that in the corresponding component,
and maybe create some kind of meta bug for gdb hooks. So debugging for
nsTArray would be filed in XPCOM, etc. I think that's the way it works for
Javascript engine related debugging hooks. Failing that, having the nested
gdb
In bug 1308652, I'm planning on removing about:bloat. It disables XPCOM
leak tracking while it is running, so running it can cause false negative
leaks (bug 1271182). I don't think anybody uses it much any more, so I'm
going to remove it.
Andrew
___
dev-
On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky wrote:
> If you want to get started before that, please make sure to
>> file a bug on what you're doing before you start. That should avoid
>> duplicating work.
>>
>
> Is there an overall tracking bug people could check to see which things
> are alrea
- Original Message -
> Talos memory measurements aren't very good because it cycles through
> multiple sites in a single tab. So it sometimes catches start-up
> memory consumption regressions (Firefox Health Report was a recent
> case) but it doesn't get much beyond that.
Another problem
- Original Message -
> Does this also apply to code holding on to JSObject*s? I've been
> adding a whole bunch of those cases lately.
If you are telling the cycle collector about those JSObjects, then it should
get fixed whenever CCed stuff is fixed.
Andrew
_
- Original Message -
> >> We could come to the compromise of running them on m-c, m-a, m-b
> >> and m-r. Only this would help a lot since most of the load comes
> >> from m-i and try. We could make it a non-by-default platform on
> >> try.
>
> I wonder if we should do the same for debug
- Original Message -
> On Apr 27, 9:37 am, Mounir Lamouri wrote:
> > Why? Wouldn't be the idea of such component to make sure it is
> > usable
> > from C++?
>
> Perhaps some day, but IndexedDB was always designed with JS in mind.
> To use it you pass special JS dictionaries for options, c
I've also come across somebody running doxygen on mozilla code here:
http://doxygen.db48x.net/mozilla/html/
It shows up in google searches when you search Mozilla-y class names, but I
don't know who or what runs it.
Andrew
- Original Message -
> I've started to run doxygen on a fresh m
That's really strange. I don't know why you'd end up with that when running it
one way but not the other.
Andrew
- Original Message -
> I am using a third party framework in my application on MAC.
>
> Third party framework uses mozilla 4.0 to display some web pages. The
> application i
- Original Message -
> Relatedly, I see Blink people recently -- well, Tab -- offer to add
> counters to Blink to determine how often particular Web features are
> used. Is that something we are also able to do, maybe as part of
> Telemetry?
Yes, it is really easy to do. For instance, bh
- Original Message -
> I think the key argument against this approach is that system components
> are never truly isolated. Sure, some of them can be compiled out and
> still produce a working system. That doesn't mean that testing without
> those components is going to have good test cov
In bug 883920, I converted these two macros into more contemporary templates.
What was
NS_HOLD_JS_OBJECTS(this, nsFoo);
or
nsContentUtils::HoldJSObjects(this, NS_CYCLE_COLLECTION_PARTICIPANT(nsFoo));
can now just be
mozilla::HoldJSObjects(this);
What was
NS_DROP_JS_OBJECTS(this, nsFoo);
Due to complaints about the classic stylings of my initial header name, you now
need to include mozilla/HoldDropJSObjects.h rather than
nsCycleCollectionHoldDrop.h for these templates.
- Original Message -
> In bug 883920, I converted these two macros into more contemporary templates.
>
Our (professedly) weekly DOM bindings meetings continue on Monday Sept 30 at
12:30 PM PDT.
Thanks to Kyle Huey for sending out these meeting notices over the last year or
so!
Meeting details:
* Monday, September 30, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Dial-in Info:
- Vidyo room: B
Our (nominally) weekly DOM bindings meetings continue on Monday Oct 21 at 12:30
PM PDT.
Meeting details:
* Monday, October 21, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Dial-in Info:
- Vidyo room: MTV-3V Very Good Very Mighty
I'm not sure if any of the below info is accurate or not. If
Correction: we're going to use Boris Zbarsky's room for the meeting, out of
habit, even though he won't be there.
Andrew
- Original Message -
> Our (nominally) weekly DOM bindings meetings continue on Monday Oct 21 at
> 12:30 PM PDT.
>
> Meeting details:
>
> * Monday, October 21, 2013,
Our weeklyesque DOM bindings meetings continue on Monday October 28 at 12:30 PM
PDT.
We will be celebrating the return of Boris with cakes in the shape of DOM tree.
(Not really.)
Remember that US times are weirdly offset from Europe this week.
Meeting details:
* Monday, September 30, 2013, 12
- Original Message -
> Is there anything else we can do to prevent this from happening again?
It should be possible to track the peak number of live DOM windows in a test.
The current number of live windows is printed out in the log as the number
right after --DOMWINDOW == or ++DOMWIND
I was having a similar problem compiling that file with regular debug builds on
OSX. I solved it by upgrading to clang 3.3.
Andrew
- Original Message -
> Started happening recently, though I'm not sure if it's my system or
> something changed in our code. Anyone else able to build ASAN
Our weekly-ish DOM bindings meetings continue on Monday Nov 4, 2013 at 12:30 PM
PDT.
http://arewemeetingyet.com/Los%20Angeles/Mon/12:30/w/DOM%20Bindings%20Meeting
Dial-in Info:
- Vidyo room: Boris Zbarsky
___
dev-platform mailing list
dev-platform@li
DOM Bindings Meeting - Monday (today) @ 12:30 PM PDT
Our weeklyesque DOM bindings meetings continue on Monday Sept 30 at 12:30 PM
PDT.
time conversions:
http://arewemeetingyet.com/Los%20Angeles/Mon/12:30/w/DOM%20Bindings%20Meeting
Meeting details:
* Monday, November 11, 2013, 12:30 PM PDT (3:3
Our weeklyesque DOM bindings meetings continue on Monday Nov 18 at 12:30 PM PDT.
http://arewemeetingyet.com/Los%20Angeles/Mon/12:30/w/DOM%20Bindings%20Meeting
Meeting details:
* Monday, November 18, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Dial-in Info:
- Vidyo room: Boris Zbarsky
- Mou
Note that we currently have a large set of intermittent 10.8 OSX opt-only
leaks-until-shutdown with the debugger:
https://bugzilla.mozilla.org/show_bug.cgi?id=942102
I don't know if these will show up on 10.9 or not, or if they really matter
that much.
Andrew
- Original Message -
> t
I filed bug 957201 for NS_WARN_IF_FAILED.
Andrew
- Original Message -
> On 01/07/2014 02:58 AM, Karl Tomlinson wrote:
> > smaug writes:
> >
> >> Why this deprecation?
> >
> > NS_ENSURE_ macros hid return paths.
> > Also many people didn't understand that they issued warnings, and
> > so
- Original Message -
> Great question! We have a tool called "GC zeal" in builds with
> --enable-gc-zeal and in all debug builds unconditionally. It adds a
> small runtime overhead, but gives us fine-grained control over when GC's
> happen and adds several verification modes for debugging
Our weeklyesque DOM bindings meetings continue on Monday Feb 10 at 12:30 PM
PST.
http://arewemeetingyet.com/Los%20Angeles/Mon/12:30/w/DOM%20Bindings%20Meeting
Meeting details:
* Monday, Feb 10, 2014, 12:30 PM PST
* Dial-in Info:
- Vidyo room: Boris Zbarsky
__
- Original Message -
> The Valgrind test job does leak checking, and it's recently caught
> some leaks and caused the offending patches to be backed out. However,
> the test coverage is pretty meagre, and it's desktop only so can't
> detect leaks in IPC code.
>
> I believe the ASan builds
Looking at a recent AWSY run, in StartSettled, I see three non-window zones.
One is about 22mb and contains all the stuff you'd expect, browser.xul, various
.jsm files etc.
The second is is 2.8mb, almost entirely strings. There's one string that is
about 10,000 long, but the rest are non-notab
So how long until we set up opt-in build time telemetry? ;)
Andrew
- Original Message -
> On 3/28/14, 2:16 PM, Chris Peterson wrote:
> > warp is Facebook's new C/C++ preprocessor, written by Walter Bright (in
> > D, of course). They claim build time (not just preprocessing time) of
> > 10
I just enabled LeakSanitizer (LSan) for ASan Mochitest runs on inbound, in bug
988041. LeakSanitizer is a special mode of AddressSanitizer that detects when
allocations are not freed by shutdown, and reports the allocation stack for any
such leaked blocks. We already have good coverage in debug
- Original Message -
> Jonas, I would be really interested in your thoughts. Try as we might (in the
> WebSerial API docs, at least), noone could actually think of a use case
> where providing access to a physical (RS232), or Virtual (VirtualUSB or
> VirtualBluetooth) serial port could be a
This looks really great!
How many alerts is this thing going to generate? Could you have a mailing list
that just gets all of the telemetry alerts email and then people could
subscribe to it if they wanted? (Technically, I suppose I could make a mailing
list myself and land a patch to subscri
- Original Message -
> FWIW, I've often made changes like this when touching files like
> nsCOMPtr.h or nsINode.h -- or switching nsresult from a typedef to an
> enum class! -- and I find just doing ./mach build binaries works fine.
> It reports errors randomly from all over the tree, but t
Generally speaking, I use git for everything except pushing to inbound and try,
and I use moz-git-tools to intermediate my interaction with hg.
> a) Landing code to inbound, fx-team, aurora, etc
For this, I keep around hg repos for the repos I care about, which is m-c and
inbound right now, the
1 - 100 of 140 matches
Mail list logo
