This patch makes mojo:debugger automatically connect to window_manager
only when run by skydb, so that running the debugger for tracing and
profiling doesn't bring the side-effect of spawning window_manager.
Note that we might in the future change this to make the connection to
window_manager lazy when load() or reload() is requested, but this would
require a more involved change to skydb. The way taken in this patch
doesn't change the skydb codepath while enabling usage of debugger for
interactive tracing / profiling.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1157253007
Sky debugger is a native mojo app that puts up an http server and talks
to other mojo apps in response to http requests, allowing to
interactively start/stop tracing, profile, etc.
This is generally useful also when one does not run mojo_shell through
skydb, hence this patch pulls the debugger into services/debugger.
We can then add plumbing for running with the debugger in devtools.
Bug: domokit/devtools/#4.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1151573010
Having the output of the tracing service be a list of json objects
instead of one json object makes it much easier to combine multiple
sources. This teaches skydb (which wants to format the output into a
json file loadable by trace-viewer) to emit the tracing header/footer
itself. This will make it possible to combine data from the tracing
service with data collected by the shell itself.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1065093003
This flag to mojo_shell is gaining the ability to produce tracing info
starting very early in process startup. This allows the skydb 'start'
command to pass this command through to mojo_shell.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1065723003
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
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
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
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
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
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
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
--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
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
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
We keep seeing timeouts on the bots that seem to be due
to cherrypy dropping requests on the floor, which in turn
causes imports to stall, which causes the test to time out.
In local testing, I was able to reproduce the timeouts
and wasn't able to do so with the go-based server.
R=abarth@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/746373002
Previously, skydb could be used only for Debug builds. As part of working on
graphics performance, I'd like to use it for release builds as well. This CL
teaches it to use the same configuration arguments as sky_server, test_sky, and
test_perf.
The downside of this CL is that you'll need to supply --debug in the common
case of working with a debug build.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/746473003
This script isn't quite working, but it's valuable to checkpoint the work at
this point. I'm coordinating with the chromeperf.appspot.com folks to get the
server to accept the data.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/702603005
Turns out that the /sky mapping to the gen
directory was interfering with our new pattern
of mapping the actual /sky directory.
So now we use a more restrictive mapping pattern
of only mapping /sky/services, similar for
/mojo/services and /mojo/public.
Fixed an exception of not finding _sky_server
when a custom sky_server was already running.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/692163002
Automatically shut-down the sky_server when quitting.
Always start the skyserver at the mojo-root
instead of the parent directory to the path.
Log when starting a sky_server outside the mojo root.
Re-use already running sky_servers when possible.
R=esprehn@chromium.org, abarth@chromium.org
Review URL: https://codereview.chromium.org/679333005
