GetCurrentThread() returns a pseudo handle, so comparing it against
the passed in argument doesn't make sense in most cases. This patch
changes it to using the thread id for comparison, which is guaranteed
to be unique in the whole lifetime of a thread.
MozReview-Commit-ID: 5TNAgLkcS6m
--HG--
extra : rebase_source : 0e72e8f6196c8079086ca697b9a121c6987ef43e
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
We are apparently still crashing even after mprotect() with write flag
returns successfully. This patch reads the flags again after mprotect()
returns, and hopefully the flags will tell the truth of whether the page
is truly writable or not after calling mprotect().
MozReview-Commit-ID: Jsg8vHKFEvJ
--HG--
extra : rebase_source : b028aa0d5cefd50302bfc2502292d9129d202e09
This also changes many references to the 'pseudo stack' to refer to the 'label
stack' instead. The label stack is one of the two stacks that are managed by
the profiling stack, the other stack being the JS interpreter stack.
MozReview-Commit-ID: Ed0YMMeCBY8
--HG--
extra : rebase_source : 5675d670f424c7d7dda04bafc2b3431fa2485e3c
The term "entry" is already used for elements in the profile buffer.
MozReview-Commit-ID: 1aB22V6veQh
--HG--
extra : rebase_source : c664eb4d6bed6cb74ba8a1b67ea99bd8ca57bcf7
extra : source : 3264c0cc0027b240b55bd3aebf27263b1e1d1cc0
The name Cpp was confusing, because C++ functions are in the native stack, not
in the pseudo stack. The pseudo stack only contains frames for manually
instrumented code that uses AutoProfilerLabel, and JS frames.
MozReview-Commit-ID: 9ptfhREo0qy
--HG--
extra : rebase_source : 76a1a32acb4c946aeb2ad45e904e419c1c9e2ad1
It was necessary back when we were doing decompression from a signal
handler, because we couldn't then have zlib call malloc, but we don't
do that anymore, so the whole wrapping is effectively unused.
With the wrapping gone, we manually initialize the zalloc, zfree and
opaque fields, as specified in the zlib documentation.
--HG--
extra : rebase_source : c4e84009e65f71f6c43362468c2934e04a8abda1
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 596f590443f727d1a79582202eed122f79ae85cf
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 02bf7337fa9a6d1194809c224acb4a2690fd87a3
That NDK bug has been fixed since r8c, and we now require something more
recent than that. This effectively reverts the changes from bug 720621
and bug 734832.
--HG--
extra : rebase_source : 9ff76a790ec4135dc0172cfd0f11fc1ecef7df64
BasicDllServices is a simplified implementation that allows programs other than
Firefox to link against mozglue and access DLL services without requiring any
XPCOM baggage.
To reliably detect corrupt APK, this patch adds a GeckoLoader.verifyCRC
call to enable verification of CRC before extracting libs.
MozReview-Commit-ID: 5EpIfwREGIv
This removes the need for the content process to have permissions to create new
files on macOS, allowing more aggressive sandboxing.
MozReview-Commit-ID: 8agL5jwxDSL
--HG--
extra : rebase_source : 17ebcef3e9d24f3d4e7515e3fae95e65cef76a79
MozReview-Commit-ID: 270iURVhNRu
This patch builds upon the existing DLL services functionality:
1) We add code to obtain the name of the subject from the cert used to sign a
binary (if present). This code is added inside mozglue because in the future
we will be using this code from the DLL blocklist, which is also located
there.
2) We add annotation functionality that registers itself for DLL load events
and updates crash reporter annotations as new libraries are loaded. It also
annotates any existing libraries that are also in memory at the time that the
CertAnnotator is first instantiated. This all happens off main thread, with
the exception of actually making the annotation when in a child process.
--HG--
extra : rebase_source : 2e3726d37356479aee81915caed04fe7af74c815
MozReview-Commit-ID: 270iURVhNRu
This patch builds upon the existing DLL services functionality:
1) We add code to obtain the name of the subject from the cert used to sign a
binary (if present). This code is added inside mozglue because in the future
we will be using this code from the DLL blocklist, which is also located
there.
2) We add annotation functionality that registers itself for DLL load events
and updates crash reporter annotations as new libraries are loaded. It also
annotates any existing libraries that are also in memory at the time that the
CertAnnotator is first instantiated. This all happens off main thread, with
the exception of actually making the annotation when in a child process.
--HG--
extra : rebase_source : f86c1a6fd2a44f21a71e7a7418267b3b0d5feeec
MozReview-Commit-ID: 270iURVhNRu
This patch builds upon the existing DLL services functionality:
1) We add code to obtain the name of the subject from the cert used to sign a
binary (if present). This code is added inside mozglue because in the future
we will be using this code from the DLL blocklist, which is also located
there.
2) We add annotation functionality that registers itself for DLL load events
and updates crash reporter annotations as new libraries are loaded. It also
annotates any existing libraries that are also in memory at the time that the
CertAnnotator is first instantiated. This all happens off main thread, with
the exception of actually making the annotation when in a child process.
--HG--
extra : rebase_source : e032ee8c4cf71e5225b51797443764549f4bbe56
Unified headers have a complete <elf.h> so we should include that
instead of <linux/elf.h>.
MozReview-Commit-ID: DkQv2vk1Q62
--HG--
extra : rebase_source : 7cd9eb04532c14b1dd0dc8747448b89d16e4f118
Unified headers have a complete <elf.h> so we should include that
instead of <linux/elf.h>.
MozReview-Commit-ID: DkQv2vk1Q62
--HG--
extra : rebase_source : 43b3fa15042246d2c3ec37a3ca904822b0f68d0c
It was added in bug 683127 as a forced include for nspr, and
accidentally became unused after bug 1230117, but it turns out that all
versions of Android we care about nowadays (and probably back then) now
support dladdr.
--HG--
extra : rebase_source : 024244627c215de2d35e2f4595b7612eb1723996
When looping through the debugger helper links during our
dl_iterate_phdr implementation, we effectively race with other threads
dlclose()ing libraries while we're working.
We do have a (rather involved) check in place to ensure that elf headers
are readable. But it turns out in practice, some dlclose() do happen
between the check and the actual read of the elf headers.
Unfortunately, we can't lock the system linker while we're looping, so a
better approach is to only loop through the libraries we loaded, and
rely on the system dl_iterate_phdr to iterate over the (remaining)
system libraries.
Unfortunately (again), Android versions < 5.0 don't have a system
dl_iterate_phdr, so we have to rely on the old iterator when it's not
present.
--HG--
extra : rebase_source : 3fd07589ed1939411ef72f481b7c72f761d53701
We're going to introduce two code paths that need to fill dl_phdr_info
from different iterators, so first move the code to a separate class,
that both code paths will be able to call.
--HG--
extra : rebase_source : a50663ad8d15d4f7a28d7138824003df5edd7f1c
The same exists in mozilla/MacroArgs.h, avoiding a macro redefined warning
when building on non-Android.
--HG--
extra : rebase_source : 6e3502ddf9deb96b29e3663f5867f852a2912401
Because one entry point is simpler than two, we make replace_init fulfil
both the roles of replace_init and replace_get_bridge.
Note this should be binary compatible with older replace-malloc
libraries, albeit not detecting their bridge (and with the
previous change, they do not register anyways). So loading older
replace-malloc libraries should do nothing, but not crash in awful ways.
--HG--
extra : rebase_source : aaf83e706ee34f45cfa75551a2f0998e5c5b8726
The allocator API is a moving target, and every time we change it, the
surface for replace-malloc libraries grows. This causes some build
system problems, because of the tricks in replace_malloc.mk, which
require the full list of symbols.
Considering the above and the goal of moving some of the replace-malloc
libraries into mozglue, it becomes simpler to reduce the replace-malloc
exposure to the initialization functions.
So instead of the allocator poking into replace-malloc libraries for all
the functions, we expect their replace_init function to alter the table
of allocator functions it's passed to register its own functions.
This means replace-malloc implementations now need to copy the original
table, which is not a bad thing, as it allows function calls with one
level of indirection less. It also replace_init functions to not
actually register the replace-malloc functions in some cases, which will
be useful when linking some replace-malloc libraries into mozglue.
Note this is binary compatible with previously built replace-malloc
libraries, but because those libraries wouldn't update the function
table, they would stay disabled.
--HG--
extra : rebase_source : 2518f6ebe76b4c82359e98369de6a5a8c3ca9967
These flags are only relevant on OS X, and will not be necessary soon, so this
commit moves them to a separate variable while we move the remainder of the
ldflags to mozbuild.
MozReview-Commit-ID: 1NDgz3HIYpT
--HG--
extra : rebase_source : 6e9b5f5a5be5ff916db89a0b73896b9058eb040e
We assume CLOCK_MONOTONIC as timebase for events on Wayland and use that to translates GDK event times to gecko timestamps.
MozReview-Commit-ID: LWd2KWTQeha
--HG--
extra : rebase_source : 1839d35989b9c29c60dd33d445db79afc75af9ab
We already dealt with issues around dlsym not resolving weak symbols
with libc in bug 1081034. This fix applies the same workaround to libm,
which solves the isnanf issue.
The previous fix for looking up __isnanf is no longer needed.
The comment with the accompanying change explains things, but the short
version is that clang generates full calls to isnanf, which our
dlsym-based symbol lookup in the custom linker cannot handle correctly.
We therefore need to do extra work for isnanf to find the correct symbol.
It seemingly hasn't been needed since Mac OS 10.7. A diagnostic assertion that
has been in place for a while hasn't caught any uses of it.
--HG--
extra : rebase_source : 9834849eec9174267c7df8de7fd22840ffa36d8f
As long as symbols have the right declspec, the linker is going to
export them as expected. The main exception to when we actually need the
exported symbol to have a different name, which is the case for the
symbols normally exported by the CRT. So keep only those renamed symbols
in mozglue.def.in.
Keeping the jemalloc symbols in this file kind of implies that we need
every new API entry points to appear in there when it's not true. This
thus removes an unnecessary moving part when adding new allocator API
entry points.
--HG--
extra : rebase_source : 76faa659d62d46f3624fe3f1df0c09beb68e3549
For obscure linkage reasons, we need all the replace-malloc symbols
being passed to the linker to tell it to allow them being undefined.
That list actually duplicates what's in malloc_decls.h somehow, and
every time we add an entry point, we end up having to modify those two
files (and others, addressed in different bugs), which is suboptimal.
So we generate the list of those symbols from malloc_decls.h.
--HG--
extra : rebase_source : 50156c6dda5601a6437f94a753400ec4ed9c8343
jemalloc_ptr_info() gives info about any pointer, such as whether it's within a
live or free allocation, and if so, info about that allocation. It's useful for
debugging.
moz_malloc_enclosing_size_of() uses jemalloc_ptr_info() to measure the size of
an allocation from an interior pointer. It's useful for memory reporting,
especially for Rust code.
--HG--
extra : rebase_source : caa19cccf8c2d1f79cf004fe6a408775de5a7b22
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : 27b1dda404b3fc5fab95dd524677387bad921751
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : 1039c3f8669093c9d77a3c30090c76457c8eb6e8
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : d932e84ff0729b1c5ccff6658ee81849eb27eef4
Report init failure if uncompressed stream size is 0.
Check for overflows when casting.
Verify LZMA stream only has a single block.
Detailed error logging.
MozReview-Commit-ID: DZ4cWGxAzkw
--HG--
extra : rebase_source : da66646c78e7947ffcf2325ad5bd0de9205506bf
Bug 1186064 removed most of it when we started requiring VS 2015u2, but
the "frex" function exported through mozglue.def.in was only used
through the MSVCRT being patched by fixcrt.py, which is not done anymore.
So the "frex" export is not used anymore, and so the "dumb_free_thunk"
function is not used anymore as well.
--HG--
extra : rebase_source : 879c469c317c8b6749410a4a476d6c951c9a1d0f
Use the UI thread's tid for checking if we're on the UI thread in Gecko.
This lets us get rid of `GeckoThread.registerUiThread`, in order to
avoid a race where we check for UI thread before `registerUiThread` is
called.
MozReview-Commit-ID: 11gAWgx4UZo
Just one caller (in DMD) actually looks at it, and that's in an unimportant way
-- if the return value was false, mLength would be zero anyway.
--HG--
extra : rebase_source : 0463ab3765744742a9e854964342d631095fa55f
This patch does he following.
- Avoids some unnecessary casting.
- Renames the |bp| parameter as |aBp|.
- Makes the no-op FramePointerStackWalk() signature match the real one.
(Clearly it's dead code in all built configurations!)
--HG--
extra : rebase_source : 3fe606d1ff9b063294f4028ff884c20661ed9e0a
MozStackWalk() is different on Windows to the other platforms. It has two extra
arguments, which can be used to walk the stack of a different thread.
This patch makes those differences clearer. Instead of having a single function
and forbidding those two arguments on non-Windows, it removes those arguments
from MozStackWalk, and splits off MozStackWalkThread() which retains them. This
also allows those arguments to have more appropriate types (HANDLE instead of
uintptr_t; CONTEXT* instead of than void*) and names (aContext instead of
aPlatformData).
The patch also removes unnecessary reinterpret_casts for the aClosure argument
at a couple of MozStackWalk() callsites.
--HG--
extra : rebase_source : 111ab7d6426d7be921facc2264f6db86c501d127
It appears to be unused, but it would be good to have some real-world data to
confirm this. A diagnostic assertion is a better choice for this than a
telemetry problem because stack-walking is such a low-level operation.
--HG--
extra : rebase_source : 1ebb96c5cce1b4a1c7ed09182c095af1b44a0f31
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
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
For some reason the remote decoder process will crash on some x86/Android M devices when SIGSEGV is handled by SIG_DFL. To avoid this issue and continue suppressing crash dialog, capture the signals with Android like handlers and strip debuggerd related code.
MozReview-Commit-ID: 3diOGc3OInD
--HG--
extra : rebase_source : 42017c10d13c30880f80c81b0d7487bb0d05fd44
MOZ_REPLACE_MALLOC_LINKAGE was added back when there were problems with
getting weak references working properly for replace-malloc.
Versions of OSX < 10.6 needed flat namespace, but aren't supported
anymore.
Versions of Xcode < 4.5 required flat namespace + a dummy library in
order to produce proper weak references. There is virtually nobody still
building with such an ancient toolchain.
Keeping those around doesn't /really/ hurt, except recent versions of
Xcode don't expose dyldinfo in /usr/bin, used for the configure test.
Consequently, MOZ_REPLACE_MALLOC_LINKAGE ended up being set to use the
dummy library setup, which, by using flat namespace, now causes harm in
bug 1356701, causing bug 1378332.
--HG--
extra : rebase_source : e3edc1f2cf905943c33fafeb631f2f88fc87167e
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
The linker uses zlib. The linker is in mozglue, zlib is in libxul by
default. As a consequence, we made --with-system-zlib a requirement for
builds enabling the linker.
In the meanwhile, we added an option that makes zlib built in mozglue
for different needs, which, in fact, also allows to do that when the
linker is enabled.
So, allow to build without system zlib when the linker is enabled.
--HG--
extra : rebase_source : 873a87b17b306fc392018049e01cf794b63a6206
Since bug 1307886, we don't actually use szip anymore, and don't even
have the option to package Fennec using it. We can thus remove the
support for loading them, as well as on demand linkage.
The latter might mean we can remove the segfault handler, but it's
unclear whether this is currently working around other issues with
registering signal handlers, so we'll leave that to a followup.
--HG--
extra : rebase_source : ec23cd4e78f259a70f6690adc8dfabb557e8f304
CRITICAL_SECTIONs have useful debug info that we'd like to keep around at least
on nightly, rather than having diverging signatures on crash stats we'd like to
just keep a unified implementation. As we didn't see significant perf
improvements after landing we're going to just back this out.
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
EnsureWalkThreadReady takes two locks, one in _beginthreadex and another in the DLL hook setup.
We can avoid the first by not calling EnsureWalkThreadReady if we're walking a suspended thread, since we won't be using a separate WalkThread anyway.
To avoid the hook locks, I gave in and decided to go back to setting up the hooks in DllBlocklist_Initialize as originally planned.
Profiler labels can't currently be used in mozglue, because the profiler's code
is in libxul, and mozglue cannot depend on libxul.
This patch addresses this by basically duplicating AutoProfilerLabel in
mozglue. libxul passes two callback functions to mozglue to do the actual
pushing/popping of labels.
It's an annoying amount of machinery, but it is unavoidable if we want to use
profiler labels within mozglue.
--HG--
extra : rebase_source : 4bcb6fb0f050bba42c23d92d01f9c56611f8518f
In TSF mode, application should retrieve messages with ITfMessagePump::GetMessage() or ITfMessagePump::PeekMessage() since TSF/TIP may handle the message before or after the host application handles it.
This patch rewrites the API users with WinUtils::(Get|Peek)Message() which use ITfMessagePump if it's available.
MozReview-Commit-ID: LwHIgp7SxLH
--HG--
extra : rebase_source : aa5750af9812f9b107c29546cbee6f9eede6ebfa
Fill in AArch64 trampoline for Divert(). Even though we're not using
on-demand decompression anymore, I added the AArch64 cases for
completeness.
MozReview-Commit-ID: D91KhHiDo7S
Fix printf macro mismatches where, for example, `PRIxPTR` is defined for
`long` but the ELF `Addr` type is defined as `long long`.
MozReview-Commit-ID: 8hXY1MpHPjS
This avoids many additions of `extern "C"` in C++ code and will avoid
having to do the same to mozjemalloc once built as C++.
--HG--
extra : rebase_source : af55696262f40a9dd16a19c29edcb9bb307d4957
aarch64's gcc and arm's gcc with -mfpu=neon defines __ARM_NEON for NEON, so we should detect it to support NEON code.
MozReview-Commit-ID: LRMTQLctuLV
--HG--
extra : rebase_source : 9e09eb9b67824c81dc45198acd6582584a5e1652
Add unit tests for Printf. Code coverage now at 90%. Doing better is
difficult due to the large number of assertions and failure cases, and
because some remaining untested code implements behavior undefined by
the spec, for example "%0s".
MozReview-Commit-ID: FenOur7bOt2
--HG--
extra : rebase_source : 4a399743e87912d8a72a8607dd520e676785f52d
This removes some "#if 0"s, and some related code that is also obviously
dead.
MozReview-Commit-ID: 1vEPohvdpw8
--HG--
extra : rebase_source : b7a1c08c422f0aae6538db03331773f31be33ac6
This annotates vsprintf-like functions with MOZ_FORMAT_PRINTF. This may
provide some minimal checking of such calls (the GCC docs say that it
checks for the string for "consistency"); but in any case shouldn't
hurt.
MozReview-Commit-ID: HgnAK1LiorE
--HG--
extra : rebase_source : 9c8d715d6560f89078c26ba3934e52a2b5778b6a
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
This will prevent the profiler from suspending a target thread while that thread holds the RtlLookupFunctionEntry lock, which the profiler itself also wants to use.
Xidorn Quan
Emilio Cobos Álvarez
Aaron Klotz
Jim Chen
Masatoshi Kimura
Tom Ritter
Margareta Eliza Balazs
Markus Stange
Eric Rahm
Mike Hommey
David Major
Jon Coppeard
Hiroyuki Ikezoe
arthur.iakab
Dorel Luca
James Willcox
Nika Layzell
Andrea Marchesini
Marco Castelluccio
Noemi Erli
Nathan Froyd
Sebastian Hengst
Carl Corcoran
Csoregi Natalia
Nicholas Nethercote
Gurzau Raul
Gabriele Svelto
philipp
Chris Peterson
Alex Gaynor
Tom Ritter
Cosmin Sabou
Philip Chimento
Sylvestre Ledru
Brindusan Cristian
Christian Holler
Julien Cristau
Chris Manchester
Martin Stransky
Bob Owen
Honza Bambas
Wes Kocher
Ryan VanderMeulen
Brian Murray
Carl Corcoran
Kartikaya Gupta
John Lin
Eugen Sawin
Ehsan Akhgari
Masayuki Nakano
Carsten "Tomcat" Book
Iris Hsiao
Makoto Kato
Julian Seward
Tom Tromey
Franziskus Kiefer
Eugen Sawin