Proxy source locs

[msridhar]

Basic support for proxy source locations. Also allows websocket server to be invoked as a module, so proxy server and websocket server now start together

[msridhar]

@ksen007 ok to merge?

[ksen007]

I am getting path deviation with calc.

node src/js/instrument/esnstrument.js tests/tizen/calculator/js/jquery-1.7.2.min.js tests/tizen/calculator/js/peg-0.6.2.min.js tests/tizen/calculator/js/calc.js

killall node
python scripts/jalangi.py rrserver http://127.0.0.1:8000/tests/tizen/calculator/index_jalangi_.html

export JALANGI_MODE=replay
export JALANGI_ANALYSIS=analyses/likelytype/LikelyTypeInferEngine
node src/js/commands/replay.js jalangi_trace1

On Nov 25, 2013, at 4:18 PM, Manu Sridharan notifications@github.com wrote:

@ksen007 ok to merge?

—
Reply to this email directly or view it on GitHub.

[msridhar]

Ok, I'll take a look. How do you exercise the app?

[ksen007]

Manu,

I believe that the bug got introduced in some previous checkin. You can try 3+4=*5=

Koushik

On Nov 26, 2013, at 7:23 AM, Manu Sridharan notifications@github.com wrote:

Ok, I'll take a look. How do you exercise the app?

—
Reply to this email directly or view it on GitHub.

[msridhar]

Yup, I reproduced. Will fix and add to this pull request

[ksen007]

Hi Manu,

The bug was probably introduced in a previous checkin. I do not know which one. This is a problem since we do not run the web app tests automatically.

Koushik

On Nov 26, 2013, at 9:07 AM, Manu Sridharan notifications@github.com wrote:

Yup, I reproduced. Will fix and add to this pull request

—
Reply to this email directly or view it on GitHub.

[msridhar]

Yup, I should have been running more of the web app tests; my bad. I think I know where the bug is in this case. If we can find a way to fix #5, we'd be able to do some automatic testing of web apps on Travis.

[ksen007]

I didn't notice the bug in commit f8f498b. Probably it has to do something with the websocket buffer.

Koushik

On Nov 26, 2013, at 9:13 AM, Manu Sridharan notifications@github.com wrote:

Yup, I should have been running more of the web app tests; my bad. I think I know where the bug is in this case. If we can find a way to fix #5, we'd be able to do some automatic testing of web apps on Travis.

—
Reply to this email directly or view it on GitHub.

[msridhar]

I believe I've fixed the bug. The issue was that during record, the trace could include a single line that was bigger than MAX_BUF_SIZE (due to serializing ASTs). I've tested on annex, calculator, and go now, and don't see any path deviations.

[ksen007]

A record in the trace can have unbounded length. This happens if a large string is logged. The length of a packet sent to the server can, therefore, have a length that is independent of MAX_BUF_SIZE. So socket.js should be modified to have the following definition.

wsServer = new WebSocketServer({
httpServer: server,
// You should not use autoAcceptConnections for production
// applications, as it defeats all standard cross-origin protection
// facilities built into the protocol and the browser. You should
// always verify the connection's origin and decide whether or not
// to accept it.
maxReceivedFrameSize: 64_1024_1024,
maxReceivedMessageSize: 64_1024_1024,
autoAcceptConnections: false
});

Koushik

On Nov 26, 2013, at 11:44 AM, Manu Sridharan notifications@github.com wrote:

I believe I've fixed the bug. The issue was that during record, the trace could include a single line that was bigger than MAX_BUF_SIZE (due to serializing ASTs). I've tested on annex, calculator, and go now, and don't see any path deviations.

—
Reply to this email directly or view it on GitHub.

[msridhar]

@ksen007 this issue is now addressed in analysis.js, see 6e67cf8. We break up excessively-long records into chunks before sending them to the server. I believe this will be more robust than potentially sending huge messages over the network.