How to use a debugger with Dart AppEngine apps

[Günter Zöchbauer]

I'm looking for a way to use a debugger with a Dart AppEngine (server side) app.

see also http://stackoverflow.com/questions/26807828/how-can-i-debug-a-dart-appengine-app

I think the simplest way would be to connect the Observatory to the server app, but I wasn't able to figure out how to do it.

I tried things like

ENV DBG_ENABLE 1

or

ENV DART_VM_OPTIONS --enable-vm-service=8181 --observe --debug --checked --pause-isolates-on-exit

in Dockerfile without success.

Any hint about how to make this work would be great.

It would be even better to be able to connect the DartEditor or WebStorm debugger of course.

[Alexandre Roux @ Tekartik]

I was able to connect from the darteditor, adding a DBG_ENABLE variable in my app.yaml file (value does not seem to matter according to https://github.com/dart-lang/dart_docker/blob/master/runtime/dart_run.sh)

env_variables:

  DBG_ENABLE: 'true'

Running the app locally was then displaying:

DEBUG: Container: f04d21c423c8: Enabling Dart debugger

DEBUG: Container: f04d21c423c8: Starting Dart with additional options --debug:5005/0.0.0.0

INFO: To debug module default attach to 192.168.59.103:5005

and indeed I was able to open a remote connection from DartEditor connecting to a Command-line VM with port 192.168.59.103 port 5005. However I was not able to set breakpoints yet from DartEditor. Debugging, conveniently running unit-tests and endpoints and I'll be a happy man. In the mean time, I guess I'll have to stick with java on AppEngine...

[Günter Zöchbauer]

Could it reproduce with the same result.

[Søren Gjesse]

First off the fix to issue 21067 is on the current 1.8.0-dev version, so it is not part of Dart 1.7.2 which is the latest version in the docker images on the Docker registry. I am just checking the current 1.8.0-dev, and it seems like there is still an issue with setting breakpoints. I will keep you posted.

Regards,

Søren

--
You received this message because you are subscribed to the Google Groups "Dart Server-side and Cloud Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud+un...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/cloud/.

[Günter Zöchbauer]

Thanks for the info!

What about using Observatory for debugging or does it suffer from the same limitations?

I wasn't able to connect.

[Søren Gjesse]

Günter,

Sorry I forgot to send this earlier. To enable access to the observatory you need to configura port-forwarding of port 8181 from the docker container to the doot2docker host. This is done by adding the following to your app.yaml:

network:

  forwarded_ports: ["8181"]

You should then be able to access the observatory using the docker host network on http://192.168.59.103:8181/ (replacing 192.168.59.103 with whatever you 'boot2docker ip' says).

Regards,

Søren

[Günter Zöchbauer]

Søren,

thanks for the info.

I tried this and I guess this was why I was able to connect to Observatory for one time.

I didn't fully understand how `glcoud` controls or interacts with Docker but when I change a file `gcloud` seems to rebuild the Docker image.

When this happes I get

 ---> 58f116a89c9f

Removing intermediate container d80ba3e35a45

Step 18 : ENTRYPOINT /dart_runtime/dart_run.sh

 ---> Running in 387836e9f9bc

 ---> 43243fdb1e0c

Removing intermediate container 387836e9f9bc

Successfully built 43243fdb1e0c

INFO: Creating container...

INFO: Container b1dee5280652aaebbae18a13b380980c5b9878db49c64600b9e3b2bf3b65a40a created.

ERROR: Internal error while starting instance.

Traceback (most recent call last):

  File "/home/myuser/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/module.py", line 1823, in _start_instance

    if not inst.start():

  File "/home/myuser/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/instance.py", line 274, in start

    self._runtime_proxy.start()

  File "/home/myuser/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/vm_runtime_proxy.py", line 292, in start

    self._container.Start()

  File "/home/myuser/google-cloud-sdk/platform/google_appengine/google/appengine/tools/docker/containers.py", line 519, in Start

    volumes_from=self._container_opts.volumes_from)

  File "/home/myuser/google-cloud-sdk/./lib/docker/docker/client.py", line 898, in start

    self._raise_for_status(res)

  File "/home/myuser/google-cloud-sdk/./lib/docker/docker/client.py", line 89, in _raise_for_status

    raise errors.APIError(e, response, explanation=explanation)

APIError: 500 Server Error: Internal Server Error ("Cannot start container b1dee5280652aaebbae18a13b380980c5b9878db49c64600b9e3b2bf3b65a40a: Bind for 0.0.0.0:8181 failed: port is already allocated")

INFO: Building image bwu-dart.default.dev...

INFO: default: "GET /_ah/health?IsLastSuccessful=no HTTP/1.1" 503 -

DEBUG: Health check response [''] and status 503 Service Unavailable for instance 0.

DEBUG: Health check state for instance: 0: 1 consecutive UNHEALTHY responses.

DEBUG: Performing health check for instance 0.

DEBUG: Dispatching request to <Instance 0: 0/8, total: 0 [not started handling ready request]> after 0.0000s pending

WARNING: All instances may not have restarted

INFO: default: "GET /_ah/health?IsLastSuccessful=no HTTP/1.1" 503 -

DEBUG: Health check response [''] and status 503 Service Unavailable for instance 0.

DEBUG: Health check state for instance: 0: 2 consecutive UNHEALTHY responses.

on Debian Jessie.

This doesn't seem to work reliable no matter if I add this `forwarded_ports` to `app.yaml` or not though.

[Günter Zöchbauer]

This could be related to this Docker issue

https://github.com/docker/docker/issues/8714

[Søren Gjesse]

Günter,

On Fri, Nov 21, 2014 at 5:07 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Søren,

thanks for the info.

I tried this and I guess this was why I was able to connect to Observatory for one time.

I didn't fully understand how `glcoud` controls or interacts with Docker but when I change a file `gcloud` seems to rebuild the Docker image.

The 'gcloud preview app run' command is watching the application directory (rooted in app.yaml) and when files change it will rebuild the Docker image and run that in a new container.

I have not been able to reproduce this. I am running on Ubuntu Precise, but I am not sure whether the Linux version can matter here. I have just tried with the sample 'simple_request_response' adding

network:

  forwarded_ports: ["8181"]

to app.yaml and changing and saving a file a number of times.

Could you try with just that simple example, to see if we can narrow it down?

 

This doesn't seem to work reliable no matter if I add this `forwarded_ports` to `app.yaml` or not though.

Could you please expand here. Are you seeing the same issue without adding `forwarded_ports` to app.yaml?

Regards,

Søren Gjesse

Software Egineer, Google Denmark

CVR nr. 28 86 69 84

[Günter Zöchbauer]

Søren,

you are right I couldn't reproduce with simple_request_response either.

I tracked it down to 

env_variables:
 DBG_ENABLE: 'true'

First launch works. When I then modify a file I get the error.

Do you have instructions how to do debugging with Dart and Managed-VM?

[Søren Gjesse]

Günter,

So adding

env_variables:

 DBG_ENABLE: 'true'

to app.yaml will cause issues. It enables debugging in the Dart VM (by passing the option '--debug:${DBG_PORT:-5858}/0.0.0.0' to the VM). This causes the VM to stop before main, waiting for a debugger to attach. If no debugger attaches the deployment is hanging there, and when you save a modified file deploying a new container fails as the existing one is not shut down first.

Note that if you don't set DBG_PORT in app.yaml the default value is 5005, which 'gcloud preview app run' will also print.

As a side note, you can actually attach with the Dart Editor using 'Run->Remote Connection...', using the information printed by 'gcloud preview app run'. This can start the VM running, but actual debugging is still not working, and I am not sure it will be functional with Dart 1.8.

Regards,

Søren Gjesse

Software Egineer, Google Denmark

CVR nr. 28 86 69 84

[Günter Zöchbauer]

Søren,

On Monday, November 24, 2014 10:23:07 AM UTC+1, Søren Gjesse wrote:

Günter,

So adding

env_variables:

 DBG_ENABLE: 'true'

to app.yaml will cause issues.

yup

 

It enables debugging in the Dart VM (by passing the option '--debug:${DBG_PORT:-5858}/0.0.0.0' to the VM). This causes the VM to stop before main, waiting for a debugger to attach. If no debugger attaches the deployment is hanging there, and when you save a modified file deploying a new container fails as the existing one is not shut down first.

 

This is a bug then, isn't it. Where should such issues be reported? http://dartbug.com?

Your explanation is helpful for understanding what's going on but doesn't seem to be fully accurate. 

When I connect the debugger, execution of my app was stopped on an exception because of a bug in my code, not before main.

By adding

env_variables:
 DART_VM_OPTIONS: '--pause-isolates-on-start'

I can connect the debugger and it seems server.dart hasn't yet started executing.
I see two active isolates but no stack. I assume this is the state you expected by setting 
DBG_ENABLE='true'
But from this state there seems not debugger support to continue (as you mentioned).

I also tried to set an initial breakpoint using

 DART_VM_OPTIONS: '--break-at=server.dart:17'

but I wasn't able to figure out the correct syntax yet or maybe this option doesn't work as intended (see http://dartbug.com/21690)

 

[Søren Gjesse]

The bug on debugging is issue 21280, and prior to that issue 21067 has been fixed. However all of this is on Dart 1.8, and for 1.7.2 I would not expect any of this to work.

Regards

Søren Gjesse

Software Engineer, Google Denmark

CVR nr. 28 86 69 84

[Günter Zöchbauer]

I tried with a custom built image:

 (master) $ docker exec 42d751  dart --version
Dart VM version: 1.8.0-dev.4.4 (Thu Nov 20 12:57:34 2014) on "linux_x64"

[Günter Zöchbauer]

I tried again today with 

Dart VM version: 1.8.0-edge.42011 (Wed Nov 26 14:57:38 2014) on "linux_x64"

I can connect the DartEditor debugger to the server app running inside the Docker container (as before).

The debugger shows two isolates but it seems there is nothing that can be done from here.

No continue, resume, step, ...

Should this work?

Are the fixes already included in bleeding_edge or dev builds?

Am I doing something wrong?

[Søren Gjesse]

Hi Günter,

I assume you saw that issue 21280 was marked as fixed. So I have just tested it, and it seems to work. Besides the Dart VM in the container needs to be pretty recent you also need a Dart Editor with the fix to that issue.

I have used the Dart Editor from r42014, which you can find here: http://gsdview.appspot.com/dart-archive/channels/be/raw/42014/editor/.

if you are using the google/dart-runtime base image (or the dart_run.sh script used there) you add the following to app.yaml file to turn debugging:

env_variables:

  DBG_ENABLE: 1

  DBG_PORT: 5858

Otherwise adding something like this to you Dockerfile will also turn on debugging:

ENTRYPOINT ["/usr/bin/dart", "--debug:5858/0.0.0.0", "bin/server.dart"]

This turns on debugging in the Dart VM, which means that it will stop before main and wait for a debugger to attach.

If you use the 'app.yaml' approach the running 'gcloud preview app run' command will now log the following in the console:

  INFO: To debug module default attach to 192.168.59.103:5858

To attach the Dart Editor debugger use Run->Remove Connection....

  In the 'Host:' field enter the IP address printed (same as is reported by 'boot2docker ip', the default is 192.168.59.103).

  In the port field enter the port printed (value set by DBG_PORT or the --debug option)

  And use "Select folder..." to specify the project source (see note below)

Pressing "OK" will connect to the waiting Dart VM. The Dart Editor will enable all breakpoints and start the Dart VM running. You should now hit the breakpoints you have defined and debugging should work as it does for normal standalone applications started from the Dart Editor.

Whenever the container is shutdown the debugger will disconnect and you will have to re-connect when the container is running again. The choices in Run->Remove Connection... dialog are kept, so it is just two clicks to re-attach.

Please try this out. There are probably still issues with debugging into source in packages, both local dependencies and packages from pub.dartlang.org. We will continue to work on this, but please let us know what issues you run into.

Note: The reason you have to select the project source is that the Dart VM running in the docker container might not be on the same path as the source on the host is. In fact they will almost always be on different paths, as the code in the docker container is on e.g. the path /app/bin/server, which will not be the path on the host where the source is. Therefore relative path matching is used to both set breakpoints and resolve stack frames to source. You can have numerous projects open with files having the same relative postfix. E.g. there might be several projects with bin/server.dart. Selecting the project source tells the Dart Editor where to look for the source that is running in the debugee.

Regards,

Søren Gjesse

---

Søren Gjesse

Software Engineer, Google Denmark

CVR nr. 28 86 69 84

[Günter Zöchbauer]

Hi Søren,

seems I was too impatient.

I updated to Dart build 42017 and now is just works. 

Thanks a lot for your support!

Regards

Günter