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] 2 pass linkage process
Date: Sat, 15 Jul 2017 21:04:01 -0400	[thread overview]
Message-ID: <20170615210401.eklhad@comcast.net> (raw)

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

This is a followup to my earlier email on the seg fault travails with gc.
With gc forced, jsrt crashed, and it's pretty clear why, now.
I said we wouldn't create nodes just to throw them away, but of course we do, as part of our tests.
We test createElement and appendChild and insertBefore and so on, thus creating throw-away nodes, and not to say other websites wouldn't do the same thing, just to make sure client side js is working.
So my ideas about ignoring side effects when js doesn't run to completion were silly; js can run to completion and still it will tell edbrowse about nodes that no longer exist, and edbrowse has to be smart enough not to fiddle with them.
So I implemented the 2-pass linkage process. It wasn't as hard as I thought. About 30 lines.
Build all the links that js told us to build, then only mess with those nodes that are rooted.
This is my latest push.

There was another problem however.
We created a script node dynamically, then didn't use it, so gc threw it away, but my runScriptsPending routine found it and tried to run it. Crash!
So I fixed that, then there was another problem.

I created a script that I wanted to run, and linked it into body, so it was rooted, but it still didn't run.
Problem is the scripts section is first, and the script was not rooted, so did not run, then I linked it into body below, whence it became rooted.
So I fixed that.

Now jsrt runs, even with gc forced after every script.
Also, www.ibm.com runs without a seg fault,
and that was the troublesome website that sent me down this path two days ago.

You know, all this stuff is at the very edge of what I can do and analyze and understand.
I guess that's part of the fun.

Karl Dahlke

                 reply	other threads:[~2017-07-16  1:03 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20170615210401.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).