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
This mostly works. I haven't yet set up pulling down the
system binaries from the device to the host so that symbols
appear correctly, but I'll do that in the next patch.
One of the crazy things this patch adds it a script
to watch for loads on adb logcat and set up mappings
from the cache library names to the symboled binaries
in the out directory. Presumably other scripts may
want to share this functionality so I've made it its
own script.
Better would be to have mojo_shell spit out a file
including the cache mapping information and we could
watch that file instead of logcat, but this works
for now.
R=qsr@chromium.org
BUG=
Review URL: https://codereview.chromium.org/848013004
Previously, the trace coordinator would try to write a trace to the file
system, but it is awkward to write to the file system on Android. Instead, we
now stream the trace data to a data pipe. The Sky debugger consumes that data
pipe and sends it to the host via the command HTTP server.
R=eseidel@chromium.org, jamesr@chromium.org
Review URL: https://codereview.chromium.org/853943005
Add a simple example based on the window and view managers.
The skydb app can now handle apps that want to embed another view.
Corrected a problem in unique module name generation. An otherwise unique module name could be shadowed by a parameter name (service_provider in ViewManagerService Embed). Appended a "$" suffix to module names to avoid the collision.
BUG=
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/845103004
This fixes 3 little bugs in skydb:
1. Adds a logcat command to make it easy to see android logs
2. Fixes using relative build dirs in skydb start
3. Stops sending /quit to debugger.cc since mojo shutdown
doesn't actually work (crashes).
--gdb is still broken, but I'll fix that in a second change.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/852483002
I changed skydb start to take a build directory
and read the configuration out of gn args instead
of --release, --debug, etc. This should be more
flexable and handle all the crazy asan cases
mopy/config.py tries to. Once we merge sky/tools
into mojo/tools we should make mopy/config use this
method too.
This follows similar patterns to what
mojo/tools/android_mojo_shell.py does, but doesn't
use as much of the (old) android_commands and forwarder
logic. We could even remove all of that
build/android/pylib code by calling the (new)
adb reverse instead of using Forwarder (in a later patch).
This still only supports a single skydb running
at once, but it should be trivial to move the
skydb.pids file into the build directory or to have
it support more than one instance. The big question
there is what the command-line usage should look like
when supporting more than one running instance. See
the mojo-dev thread on the subject.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/816693006
This makes skydb pass a command_port to prompt.cc
as a commandline argument. I removed passing of the
url and instead pass the url via a separate /load command.
This has the nice side effect of guarenteeing that
the sky instance is up and ready to respond to commands
when skydb exits. It also prepares us for running
more than one copy of prompt.cc as jamesr requested
for both Release and Debug or for on both your android
device as well as your local machine.
R=abarth@chromium.org, jamesr@chromium.org
BUG=
Review URL: https://codereview.chromium.org/841113003
This makes it much easier to work with a device where we
don't expect a persistent commandline session. Prompt no longer
actually makes a prompt but rather just runs an http server.
This is just a v1 patch. It doesn't work with android yet
and it isn't smart enough to allow you to run more than one
copy of prompt.cc at the same time (since you can't control
the port it listens on). If you have a second copy of
prompt runnning (or anything else bound to port 7777) it will
just crash.
We could make this a lot better, including splitting out the
pid-file tracking for sky_server into sky_server instead of
having skydb manage it.
R=ojan@chromium.org, abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/840973002
Enable Sky applications to be written in terms of the Application,
Shell, ServiceProvider classes.
Add a shellProxyHandle() method to the Sky Internals class. It returns
a message pipe handle that the JS Shell class will assume ownership of.
BUG=
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/837283002
1. If notifyTestComplete is called before the first paint,
give a clear assert instead of a confusing crash.
2. Add runAfterDisplay. This is a copy of the equivalent
file in Blink. Avoids the incorrect 100ms setTimeout. I had
thought there was a deeper bug here, but it appears to just
be the issue from #1 now that we properly pump frames
in testing mode by using a face Surfaces application.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/826343003
This is a proof of concept for replacing ui/views
code with Sky instead. erg says this will allow him
to delete 10s of thousands of LOC from mojo.
Mojo does not yet expose the current binary's URL:
https://docs.google.com/a/chromium.org/document/d/1AQ2y6ekzvbdaMF5WrUQmneyXJnke-MnYYL4Gz1AKDos
So I've worked around that by passing the url
of the binary via the helper script.
I discovered several bugs in the wm_flow code
including that it doesn't handle view resizes
(during embiggen). Related, I discovered that
every time a new window is made it drops the
connections to the embedded.cc app from the
previous window, since the ViewManagerDelegate
is incorrectly implemented as part of the
ApplicationDelegate on both app.cc and embedded.cc.
We'd need to split out a separate per-view object
in both of those apps to handle the
ViewManagerDelegate calls.
There are some changes to logging during loading
as well as the CopyToFile helper to have better
error reporting. I hit several issues early on trying
to get mojo to load the http: urls correctly, including
eventually running out of disk space on my /tmp
and mojo then silently failing to launch the app
(due to mojo never clearing its caches crbug.com/446302).
I had to re-write the mojo_demo.sh script in python
as well as split the sky_server handling code out of
skydb into a separate python module in order to cleanly
launch sky_server. We could use a separate server
if we wanted to but the primary benefit of sky_server
is that it sets up the proper url->disk mappings into
the generated file directories, etc.
BUG=443439
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/817573003
