edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: edbrowse-dev@lists.the-brannons.com
Subject: [edbrowse-dev] a crude 'step'
Date: Wed, 10 Jul 2019 02:20:53 -0400	[thread overview]
Message-ID: <20190610022053.eklhad@comcast.net> (raw)
In-Reply-To: <alpine.DEB.2.21.1907092035320.2680@carhart.net>

[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]

Ok I tried to do what you wanted, since it sounds useful, but with a few caveats.

I am currently debugging a site where the trace function in jects an alert that causes a syntax error.

if(condition)
var x = stuff;
else
other stuff;

I key on the word var as a safe place for me to inject trace code, but this one is not safe.

alert("c334"); var x = stuff;

Causes a syntax error.
Worse, if there wasn't an else clause, there would be no syntax error,
and my tracing would just fuck up the way the code works.
Not sure what to do about that.

Why anybody would put a var variable in the if clause, where it can never be used again,
because as soon as you hit else it is out of scope,
why anybody would do that I don't know,
but it illustrates that my trace injecting code will never be perfect, and sometimes needs some manual cleanup.
So we need to deminimize once,
then snapshot locally,
then trace once,
then put the trace js files in place of the previous js files,
then manually clean them up in case I injected a syntax error,
then use those files forever more for debugging.
So I don't want a system where you have to say uvw trace again for different start points etc.

Now with all that in mind, the new macro is eval($step+"(location)");
	(The original bp and bpl macros are still there.)
It respondse to the step level, which is global.

$step$lev = 0  do nothing
$step$lev = 1 print out the location of where you are
$step$lev = 2 activate a breakpoint indicating the current location

In the breakpoint you can change $step$lev of course.
You can put it back to 0 because maybe you're not interested in the first time you hit this block of code, but maybe the second or third, and sure enough it comes back to life when you get to it again.
$step$start turns it on.
So in my base file, before the first javascript, I added this

  <script>$step$lev = 0, $step$start = "c2682";</script>

It is then silent until it gets to c2682.
Then it breaks where it can, and I now break at more points, again, hoping not to inject syntax errors.
It's all in startwindow.js line 3340
and maybe you can improve on it;
it's a gross mash of perl regular expressions plus the stripping done by tools/uncomment.
Not for the faint of heart!
The basic idea is to trace or break before var variables, or after
function(args) {
try {
catch (e) {
if(condition) {
else {
for(conditions) {

This is designed to work with the code that is produced by the deminimizer, and will probably be a disaster if run on any other kind of code.

Even as I write this I'm a little paranoid about

if(condition)
var x = stuff;

with no else clause which will cause no error but the tracing will change the way the code runs;
and I wonder if I should get rid of the tracing before var.
I don't think you would lose very many trace points, if all the others are working.
Usually one of the other lines comes just before the var line, so you wouldn't lose anything, and those lines are safer.
Let me know what you think.

Well all this is kindof harder to explain than to write, so send me private email or message if you have any questions.

Karl Dahlke

  reply	other threads:[~2019-07-10  6:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10  3:50 Kevin Carhart
2019-07-10  6:20 ` Karl Dahlke [this message]
2019-07-11  3:42 [edbrowse-dev] a crude "step" Kevin Carhart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190610022053.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).