ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Fri, 2014-04-11 at 12:31 +0200, Benjamin Zeller wrote: 

> with Unity8 on the desktop and on our devices there will be only one way
> to start a application.


I think that we should look at this slightly differently: The system
requires knowledge and management of applications from before they're
started until after they die. Cradle to grave, we want to be active
participants in the process not just getting random connections and have
to figure out where they game from (*cough* BAMF *cough*).


> This will be done with a application launcher called
> upstart-app-launcher (UAL). However this will
> make debugging of applications impossible if the launcher has no
> debugging support build in.



The process starting and stopping is handled by the init system (Upstart
currently) with a small set of wrapper libraries and scripts that is
UAL. This causes applications to start in a consistent environment and a
known way with appropriate communication to the application manager
about them starting and stopping.


> Imagine a gdb debugger that runs somewhere in a detached process, it
> will just no be controllable,
> also when the application detaches from the starting terminal there is
> no way to control it directly like
> we need to do from QtC.
> 
> I hit this problem while working on debug support for the phones, and
> wrote a document that
> summarizes how we could handle this problem:
> 
> https://docs.google.com/a/canonical.com/document/d/1ODZjYjpMre2T-IFuFdBmzee4G0MRSsU4DbRkuZhts7o/edit?usp=sharing


I'm gonna got ahead and cut-and-paste this here so we can talk about it.
(which seems to have messed up the numbering some, but I think it's
okay)


> This means the launcher needs to have support for debugging
> applications. For applications on the phone we would need to do the
> following:


I disagree with this. Implying that we need to do what you recommend is
not really conducive to discussing the issue ☺


>      1. Add support for debugging to upstart-app-launcher:  For
>         remotely running applications that can easily be done with
>         patching the exec line while the application is started. We
>         need to tell UAL what to enable exactly so there are two ways:
>         
>              1. specific switches to enable debugging modes:
>                 --cppdebug, --qmldebug, --htmldebug
>                 
>              2. generic switches to inject arguments or prepend
>                 something to the whole exec line itself:
>                 --prepend-exec=”gdbserver :10000”  and
>                 -prepend-arguments="-qmljsdebugger=port:10001,block".
>                 This would ultimately solve all cases or we end up
>                 adding switches for every tool that should be
>                 executed 


This seems to be to be one debugging use-case. The developer wants to
alter an environment variable or a command line parameter, probably get
more logs or other information. It seems to me that it is likely the
developer in this case wants the application to work as closely to
normal as possible, including connected into the system in the same way
(urls registered, content hub, etc.).

I think the best way to achieve this is to create a click package with a
new version that has the appropriate debug flags enabled for that
developer. One of the advantages that we have with click is that we can
install the package for a particular user, or several, and we handle the
garbage collection already. So it should be easy to install and updated
debugging package and then go back to the other installed version. Or to
have another user on the system that doesn't have the version with
debugging.


> For local running apps, debugging is different, because as mentioned
> before gdb can not run in a process that has no output terminal or it
> can just not be controlled.
> 
>      1. Make upstart-app-launch not exit after starting the app when
>         running in debug mode, instead it has to act as a proxy
>         application and take the users input to the running
>         application and forwards the output of the application to the
>         controlling terminal. So a possible running
>         gdb/valgrind/whatever-tool instance can be controlled
>         
>      2. Install the apps as click packages and give the developer the
>         choice to override apps. This will be implemented as a
>         “override installed applications” checkbox in the QtC
>         Deployconfiguration widget. It will be unchecked by default
>         and the deployment will fail if the application is already
>         installed.


As you mention running a live debugger requires a lot more control over
the process and how it works. I think a better solution here would to
create an application wrapper that sets up the debugging appropriately
and starts the application in that environment. In the command line
world this would be "gdb a.out" but we'd be doing something slightly
different for a device, but we effectively want the same type of
interaction. So we have the wrapper startup first and build up the
debugging environment, perhaps running gdb and setting up a socket on
the filesystem, it then waits for the host machine to connect to that
socket and control the execution of the app. Here the starting process
gets full control over the console and everything else as it brings up
the application and can provide a plethora of debugging over the wire.


> Implementing debugging support inside the launcher is done in other
> platforms, for example iOS.


It's nice to think that we'll have a better solution than a dominate
player ☺


> Other options we discussed for QtC and the SDK, like patching the exec
> file on click-package creation are also only hacks, we have no idea at
> package creation time if the user just wants to deploy the application
> to the device or actually will run it (since those steps are separated
> in QtCreator).


Sounds fixable. You for instance have different builds for whether the
symbols get included for debugging or whether they're stripped. You do
have some intention of what the developer is wanting to do, it's not
just at "packaging" time. There's no reason that the command for "run on
device" couldn't have the steps of "build package; deploy package;
launch app".


> So if we enable debug mode in a click package and the user tries to
> start it from the shell it will just block.
> 
> Also we have no way of uninstalling a package after the the
> Application finished running on the device, because there is no
> “undeploy” step in QtC and as mentioned before, the user could just
> deploy to the device without even starting the app, that means even if
> we would add some sort of hack after QtC finished running the app it
> will maybe never executed. 


If there's no way to clean up a device after using it for debugging in
QtCreator I think that's a bug that should probably be filled upstream.
Even if it's deleting one temp file, the tool should have a way to do
it.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part