Until now, we were saving downloaded file to the temporary directory
with a name being the hash of the file content. It means there is a race
when the same content is downloaded from 2 different URLs.
To fix this, we now create an intermediary directory that is the hash of
the URL.
Also, because this is only needed for debugging with gdb, and this is
inefficient in term of both CPU and storage (we do not know when to
delete the temporary directory), we control this with a command line
flag.
R=ncbray@chromium.org, eseidel@chromium.org
BUG=https://github.com/domokit/mojo/issues/61
Review URL: https://codereview.chromium.org/1011333003
Before this change Sky would hit 404s when trying to
load examples from domokit.github.io.
I also added a separate sky_home and updated the default
url to point to sky_home instead of home.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1016143002
Dart actually expects package: to work. This CL makes package:foo
map to /packages/foo, similar to how Dartium or bin/dart would expect.
This also means overlaying the /gen directory over the actual package
outputs (as consumers of an SDK would expect) as well as adding
an additional /lib indirection for the actual package source as
the Dart pub tool will expect.
This is far from perfect, but it unlocks us actually producing a
sky SDK.
I expect there may be some fallout from this change as I'm sure I
missed some package: uses. We also don't have a general solution
for all /foo/bar/baz includes which randomly included parts
of mojo's source directory. Those will need to be updated to use
a package: and deploy_sdk.py taught how to build a package for them.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/990493002
- New chromium clang rules require explicit external destructors so
system/lib added for MessagePipe, DataPipe and SharedBuffer
- New chromium clang rules require override and no virtual in
declarations, so many files updated.
- cc_strip_video patch updated.
BUG=
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/988693005
This is basically skydb v2, except only for android.
I revisited some of the architecture decisions I made
in writing skydb. I also separated skyserver.py from
dependency on skypy/paths.py since it wasn't really adding
any value.
We could make this way fancier, but this should at least
make working with SkyDemo.apk easier for now.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/960233007
This patch allows to specify a full NetAddress on which the server is to
be set up.
This is needed to decide between running the server on externally
visible address (like http_handler would like) and localhost (like skydb
would like).
No change in behavior of existing clients in the Mojo repo should occur.
A follow-up patch will switch some of the clients from 0.0.0.0 to
localhost.
BUG=460908
R=qsr@chromium.org
Review URL: https://codereview.chromium.org/953513002
This switches to using StrongBinding<>s in sky's ContentHandlerImpl
and TestHarnessImpl implementations.
These are the last uses of the deprecated InterfaceImpl<> helper in
the mojo repo (more uses exist in other repos).
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/934403002
Unfortunately, using --origin on Linux is slow and too painful to use at the
moment. We should work on fixing that, but currently many of us have this in
our local working copy anyway.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/922823002
The tracing service logically provides one service, TraceCoordinator, which can
start and stop tracing sessions. It also can connect to any number of
TraceControllers each of which can supply tracing information on demand.
Whenever an app connects to the tracing service, the tracing service attempts to
connect to that app's TraceController interface. If the app provides this
interface then tracing data will be requested whenever tracing starts. If the
app doesn't, then the pipe just closes. Thus apps that want to be traced can do
so by creating however many connections to the tracing service they want and
registering a TraceController implementation on each outgoing connection.
The shell connects in a similar fashion by connecting to the tracing service and
providing a TraceController implementation. The code looks a bit different since
the shell is special.
BUG=451319
R=viettrungluu@chromium.org
Review URL: https://codereview.chromium.org/791493006
Before we start adding more uses of mojo app ids we should use
to a non-broken hash function. :)
What was holding me back before was I wasn't aware of us having an
incremental hash api other than base/md5.h (others in base only operate
on the full input data), however it turns out that the crypto/ library
has one in crypto/secure_hash.h.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/868253006
Already other applications use sky's simple window
manager (mojo:sky_debugger) as a full-screen window
manager. This moves this to /services and removes
all sky references from it.
As a part of this I've removed inspector support
from skydb. It was already broken and will need
to be re-thought to not involve calls into
this new window manager.
I'm also flipping the relationship between prompt.cc
and debugger.cc for skydb. Skydb will tell mojo_shell
to start sky_debugger_prompt instead of sky_debugger.
I'm also renaming sky_debugger_prompt to be
sky_debugger.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/883983004
This CL simplifies the sky_server to only map the build directory into /gen,
which will make the deploy script simpler. This CL updates all the imports to
use the /gen prefix when referring to generated files.
TBR=eseidel@chromium.org
Review URL: https://codereview.chromium.org/881093003
I also fixed skydb to use --args-for sky_debugger to
automatically issue the load from 'start' even when
the --gdb option is present.
I tried to invoke gdb_attach directly from within start_command
but that seemed to cause some strangeness with my zsh shell
where it would automatically suspend gdb. So I'll revisit
that change in the next patch.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/880143002
sky_debugger will load the default url in every view that it's
asked to embed. Think of the default_url as being like the
home-page in a conventional browser.
I also fixed prompt.cc to not terminate the entire mojo
environment when it can't start itself, but rather just
quit its own application.
With this patch I'm able to hack up mojo_shell to be able
to have a sensible default behavior when clicked from
the Android homescreen, but I'll land those hacks in a
separate change.
TBR=abarth@chromium.org
BUG=451620
Review URL: https://codereview.chromium.org/875183002
Many of the .so files in out/Debug are hundreds
of megabytes in size. md5sum can take seconds
to churn through them all, so I've added
a small caching layer which makes this script
take no time in the common case.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/865463004
This replaces my previous --gdb work:
https://codereview.chromium.org/848013004/
And obsoletes my build-id based attempt:
https://codereview.chromium.org/788903011
Context:
mojo_shell downloads arbitrary binaries from
urls copying them to temp files before calling
dlopen. Because the names it used were random
this broke gdb, pprof, etc. tools which wanted
to make address -> symbol translations based
on the library load path.
The major thing this change does is move away
from the previous method of watching the logs
of mojo_shell for 'Caching %url as %file...'
messages or the /tmp/mojo_shell.%pid.map
file to having mojo_shell use a priori knowable
names for all of its library loads. Thus
we can similarly build a directory of correctly
named symboled binaries corresponding to the
expected load names of libraries.
This change does this in 3 pieces:
1. Introduces the concept of 'app ids' (which
are currently just the md5 of the distributed app
binary) and teaches dynamic_application_loader to
rename all apps to APP_ID.mojo before loading them.
This has the nice side-effect of always loading
an app with a dlopen/library name which is both
unique to the application as well as predictable.
2. Re-writes the mojo_cache_linker script to
no longer watch stdin/adb logcat for 'caching...'
messages and instead build a links directory
based on pre-determined app_ids (md5s) linking
back to the symboled binaries.
3. Remove a bunch of the former mojo_cache_linker
calling code which is no longer needed now that
the library_names of loaded application .so's are
predictable before launching mojo_shell
I'm happy to make app_ids fancier, originally I
was going to use ELF's build-id's directly:
https://codereview.chromium.org/788903011
but unfortunately gdbserver does not know
how to do a build-id lookup on the serverside:
https://groups.google.com/a/google.com/forum/#!topic/gdb-discuss/Fd0R-gFaqXkR=aa@chromium.org, abarth@chromium.org
Review URL: https://codereview.chromium.org/866383004
This removes the symmetrical nature of ServiceProvider and consistently
passes and uses a ServiceProvider + ServiceProvider& pair in places that
wish to bidirectionally expose services, such as the view manager.
The
view manager library now deals with InterfaceRequest<ServiceProvider>
and ServiceProviderPtr objects (i.e. c++ wrappers for handles) instead
of a concrete implementation of ServiceProvider to make it easier for
callers.
A number of places that were assuming a particular
ServiceProvider would always exist are updated to reflect the nullability
of the parameters in mojom and places that do not wish to ever look up
or provide services now pass nullptr instead of doomed pipe handles.
The JS application startup classes are reworked a bit to accomodate
exposing services on the third ConnectToApplication/AcceptConnection
parameter.
BUG=449432
R=abarth@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/858103002
--origin tells mojo_shell to map all mojo: urls
to to a new base-url instead of the build directory.
This makes skydb's mojo_shell *always* use the network
loading path, which is what Android mojo_shell does
and is more like how mojo_shell will eventually be
used.
I also fixed the disk-space leak in the
dynamic_application_loader's NetworkLoader path
by having it immediately unlink the /tmp copy
of the library after dlopen.
In order to keep pprof working I had to teach the
dynamic_application_loader to write out a map of
/tmp/file -> url mappings so that we can fix
the pprof file afterwords.
This will "break" skydb --gdb on linux in exactly
as much as it is already broken on Android, but
I'm working on a build-id based solution for both
so that gdb knows how to find symbols for
non-existant randomly named /tmp libraries.
R=abarth@chromium.org, viettrungluu@chromium.org
BUG=450696
Review URL: https://codereview.chromium.org/829183005
In order for pprof to find the symbols in the profile, we need to rename the
binaries from foo.mojo to libfoo_library.so. This CL adds that step to the
stop_profiling command in skydb.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/812573006
This only barely works. We pull down system libraries
once before we attach. The libraries we pull from
the device do not have debug symbols, but have enough
that we have decent callstacks. We launch a background
process to repeatedly update a cache directory with
symlinks into our build directory corresponding to the cache
names used on the device, however gdb doesn't watch
the solib-search-path directories to notice the links
as we add them.
Better solutions would be to add support for pulling
down full android symboled system images and using those
instead of pulling libraries off the device as well as
figure out how to get android binaries to support
build-id so that we can present a directory of build-id
associated libraries to gdb on boot and have it to build-id
based lookups of libraries instead of our current broken
watch-logs-and-add-symlinks approach.
If you know what you're doing with this you can actually
make debugging work on the device. It's not particularly
user friendly yet, but we'll work on it.
I added a build_dir member to skypy.paths.Paths
as a temporary measure before we move off of skypy's
paths and onto mopy's paths. This helped eliminate
problems with using a relative path in args.build_dir
as is common.
R=abarth@chromium.org, ojan@chromium.org, qsr@chromium.org
BUG=
Review URL: https://codereview.chromium.org/855663003
