Intermittent failure of repl connection about austin HOT 11 OPEN

Any kind of transient failure like this very often ends up being cruft having built up in various directories that the compiler / REPL use to store intermediate bits. Try blowing away out, .repl, and target.

from austin.

I tried that. Also tried with a freshly pulled copy of the Austin repo.

With Chrome, I've seen no successful attempts for the past day's focused testing, and very few successes before that.

With Firefox, things are consistently working (though only a few attempts so far).

I will continue testing later today (guess I'll start by clearing Chrome's state). So far, all I can say for sure is that I'm seeing a different pattern of network traffic when I compare Firefox with the failing Chrome cases.

Can you reliably run this in Chrome?

Actually, to be precise, I'm running Chromium: "Version 28.0.1500.71 Ubuntu 12.10 (28.0.1500.71-0ubuntu1.12.10.1)"

from austin.

Chrome is actually my default catch-all test browser (including hosting most of my ClojureScripting). I don't think I've ever run chromium.

from austin.

1. Ok, I'll poke further. I may have time later today; otherwise it won't be for a few days. I'll install chrome on this VM, and maybe try chromium on another machine. Hard to imagine that it's a chrome vs chromium problem, but guess I gotta at least rule out that possibility.

2. Argh, Github did not post my last message here. (I'm doing something wrong; this has happened a few times. Probably losing focus between multiple VMs, single-clicking on comment, and not noticing that nothing happens before blindly closing the window. Or something else...). Anyway, I had detailed the differences in network traffic between the failing and working case. Basically, on a refresh after reset!'ing the repl, the first four request are the same; the fourth returning a few lines of Javascript referring to print-fn). But, the failing browser has no fifth request, while the working browser POSTs a fifth request which becomes a long-poll.

from austin.

Got it!

The issue was not chrome vs chromium; that would have been too bizarre. But, at least that set me in the right direction.

The real issue was that I was logged in to my Google account, which dragged along all my chrome/chromium extensions. Once I realized that, it was easy to isolate the culprit: the Google Voice extension.

A frustrating SOB of a bug; who-woulda-thought to look there. But, at least I'm good now.

Do you want me to submit a patch with a warning line for the README.md?

from austin.

That is really strange. A warning is worthwhile, but I'd like to know what about the extension was interfering; presumably whatever it's doing isn't unique among chrome extensions…?

from austin.

I agree 100%. I can do the first steps of describing the visible breakage, but I don't have the tools to poke deeper; I'm less than a rank novice at Chrome's architecture and know zero about Google Voice internals.

Do you know anyone who might have a good handle on attacking this kind of problem?

Of course, it would also be extremely useful for someone else to verify this bug, and make sure that it's not an interaction of GV with something else in my environment. Do you have the time to do so?

from austin.

Some more info which may mean more to you than to me:

In both cases (Chromium with Google Voice enabled or disabled, running a clean browser-connected-repl-sample), the first four packets are the same:

• Packet 1 - GET the web page html
• Packet 2 - GET app.js
• delay for a few hundred msec
• Packet 3 - GET http://localhost:59587/6678/repl?xpc={"cn":"Igg62CCsNV","tp":null,"osh":null,"ppu":"http://localhost:8080/robots.txt","lpu":"http://localhost:59587/robots.txt"} (URLencoded, of course)
• delay for another few hundred msec
• Packet 4: POST, as follows:

Request URL:http://localhost:59587/6678/repl
Request Method:POST
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:42
Content-Type:application/x-www-form-urlencoded;charset=UTF-8
Cookie:ring-session=b8d6c869-776d-47d3-93af-e339aa21e0a2; chat-id=336c3fb2-d577-4ccf-ba5b-f19e2cf0b898
Host:localhost:59587
Origin:http://localhost:59587
Referer:http://localhost:59587/6678/repl?xpc=%7B%22cn%22%3A%22Rtr72TADp5%22%2C%22tp%22%3Anull%2C%22osh%22%3Anull%2C%22ppu%22%3A%22http%3A%2F%2Flocalhost%3A8080%2Frobots.txt%22%2C%22lpu%22%3A%22http%3A%2F%2Flocalhost%3A59587%2Frobots.txt%22%7D
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/28.0.1500.71 Chrome/28.0.1500.71 Safari/537.36
Form Dataview sourceview URL encoded
{:type :ready, :content "ready", :order 1}:
Response Headersview source
Content-length:120
Content-Type:text/javascript; charset=utf-8
Date:Mon, 30 Sep 2013 07:28:09 GMT
Server:ClojureScript REPL

With response

goog.provide('cljs.user');
goog.require('cljs.core');
cljs.core._STAR_print_fn_STAR_ = clojure.browser.repl.repl_print;

Then, the working case (GV disabled) immediately sends a fifth packet:

Request URL:http://localhost:59587/6678/repl
Request Headersview source
Content-Type:application/x-www-form-urlencoded;charset=UTF-8
Origin:http://localhost:59587
Referer:http://localhost:59587/6678/repl?xpc=%7B%22cn%22%3A%22Igg62CCsNV%22%2C%22tp%22%3Anull%2C%22osh%22%3Anull%2C%22ppu%22%3A%22http%3A%2F%2Flocalhost%3A8080%2Frobots.txt%22%2C%22lpu%22%3A%22http%3A%2F%2Flocalhost%3A59587%2Frobots.txt%22%7D
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/28.0.1500.71 Chrome/28.0.1500.71 Safari/537.36
Form Dataview sourceview URL encoded
{:type :result, :content "{:status :success, :value \"function (a) {\\n  var b : cljs.core.deref.call(null, clojure.browser.repl.xpc_connection);\\n  return cljs.core.truth_(b) ? clojure.browser.net.transmit.call(null, b, \\\"\\\\ufdd0:print\\\", cljs.core.pr_str.call(null, a)) : null\\n}\"}", :order 2}

This, of course, sits in the long-poll with no response until I evaluate something in the REPL.

The failing case never sends this packet at all.

from austin.

This (goofy) extension breaks in the same way: https://chrome.google.com/webstore/detail/dictionary-of-numbers/ahhgdmkmcgahbkcbmlkpmmamemlkajaf

from austin.

With a second confirming case, I'm happy to have the warning in the patch on gh-18 shown in the main README as well, in the " Using other browser runtimes" section.

from austin.

Hoping that this is related to the use of CrossPageChannel, and therefore resolved by #50.

from austin.