It's just a complex wrapper for free(), or equivalent function. (In practice,
all the uses end up in free().)
--HG--
extra : rebase_source : 247ea8458aa57319bd1c8366115a9b4f39ed5a33
The test helper_touch_action_regions.html uses nsDOMWindowUtils to synthesize native input events and creates some runnables to trigger the test. It expects the runnables which synthesize native input events are processed first, then the runnables to continue the test, and finally the input events are forwarded from chrome process to content process. Enabling event prioritization may change the execution order.
Wraps those runnables to synthesize native input events as priority=input and dispatches those runnables to continue the test with priority=input to make sure the execution order is as expected.
MozReview-Commit-ID: 8hkaB1FRW9T
As well as the straightforward things, this lets us remove ReadSysFile and
WriteSysFile, which in turn lets us remove TestFileUtils.cpp.
--HG--
extra : rebase_source : fc90c05352e654ffc41009d8504a9c54f394fc3f
I actually couldn't figure out a way to trigger this assertion with the
current string code without doing invalid casts, but there are things we
may want to add to the string code in the future that might risk hitting
this (e.g., move constructors, promoting various rebind methods to
nsA[C]String), so I think it's worth asserting.
MozReview-Commit-ID: 4R0dYuTfrFW
--HG--
extra : transplant_source : %B6%87I%0E%7F%21%CC2%19%CD%A7%E6TRA%9D%AEO%90%D7
This is needed for patch 4.
MozReview-Commit-ID: 4BFlTtQdtoN
--HG--
extra : transplant_source : %7C%F7%FDN%E5%7Df%0C%7D%10%EF%C0%25%B9%D6%18%1E%93%BE%A0
This is needed for patch 4.
MozReview-Commit-ID: 5ikQFIL9O0i
--HG--
extra : transplant_source : %88%80%E3%04%11%7E%7F%A4%7E%15%1B%1A%84%E2%13%3E%F6%E8%2A%1C
The simplistic shift-based hashing function creates a lot of collisions
for pointers pointing to arrays as it doesn't do a great job at distributing
the data randomly based on the input bytes.
Running with XPCOM_MEM_LOG_CLASSES=nsStringBuffer triggers an
assertion in refcount logging for nsFakeStringBuffers. These are given
an initial refcount of 1, without calling NS_LOG_ADDREF. Then,
AddRef() is called on these objects in StaticAtom::StaticAtom(), and
we tell the refcount logging system about the fake buffer, and that it
has a refcount of 0, triggering the assertion.
The first part of the fix is to call NS_LOG_ADDREF for this initial
refcount, in StaticAtom().
This first fix causes refcount logging to start reporting that the
fake string buffers leak, when XPCOM_MEM_LOG_CLASSES is not set. This
is because refcount logging is now getting told about these objects
being AddRefed at 1, which it takes to mean that an object is created.
To work around this issue, I add an array gFakeBuffers that contains
every fake string buffer we create, and tell the refcount logging
system that these objects are all being destroyed, when the atom table
is being shut down. This could result in some bogosity if the fake
buffers are "leaked" but hopefully this is still an improvement over
the current state.
MozReview-Commit-ID: 5AxoBYAlYRU
--HG--
extra : rebase_source : ba0763cb494894918141774025db525cea9f9c75
Running with XPCOM_MEM_LOG_CLASSES=nsStringBuffer triggers an
assertion in refcount logging for nsFakeStringBuffers. These are given
an initial refcount of 1, without calling NS_LOG_ADDREF. Then,
AddRef() is called on these objects in StaticAtom::StaticAtom(), and
we tell the refcount logging system about the fake buffer, and that it
has a refcount of 0, triggering the assertion.
The first part of the fix is to call NS_LOG_ADDREF for this initial
refcount, in StaticAtom().
This first fix causes refcount logging to start reporting that the
fake string buffers leak, when XPCOM_MEM_LOG_CLASSES is not set. This
is because refcount logging is now getting told about these objects
being AddRefed at 1, which it takes to mean that an object is created.
To work around this issue, I add an array gFakeBuffers that contains
every fake string buffer we create, and tell the refcount logging
system that these objects are all being destroyed, when the atom table
is being shut down. This could result in some bogosity if the fake
buffers are "leaked" but hopefully this is still an improvement over
the current state.
MozReview-Commit-ID: 5AxoBYAlYRU
--HG--
extra : rebase_source : 967520e825d26c369a11acc478d223d190137a43
For some reason, I continuously ran into windows x64 specific failures when
trying to read this heap allocated data while the main thread was paused. I
don't know specifically how this happened, but I am able to avoid it by instead
directly allocating the buffer in a `mozilla::Array` in static storage, and
copying that data instead.
MozReview-Commit-ID: 473d6IpHlc4
Carsten "Tomcat" Book
Eric Rahm
Bevis Tseng
Haik Aftandilian
Bill McCloskey
Nicholas Nethercote
Kris Maglione
Sylvestre Ledru
Andrea Marchesini
Paul Adenot
Daniel Holbert
Stone Shih
L. David Baron
Ehsan Akhgari
Andrew Osmond
Ryan VanderMeulen
Andrew McCreight
Wes Kocher
Michael Layzell
Brad Werth
Sebastian Hengst