[Edbrowse-dev] Red Hot

[Edbrowse-dev] Red Hot

[Karl Dahlke]

One of my science queries led me to this page,
http://hypertextbook.com/facts/2000/StephanieLum.shtml
run with db3 and edbrowse stops at
execute addthis_widget.js at 1
js never returns, seems to run forever, chewing up cycles in the process.
This is, sadly, one of those javascripts that Chris refers to as dog vomit,
so not clear at all how to track this one down.

Karl Dahlke

Re: [Edbrowse-dev] Red Hot

[Kevin Carhart]

More possible clues to what this is or isn't caused by:

When I run this page in the i686 static build, it loads immediately.
When I run it in my ancient 3.3.1, it is slow but eventually completes.



On Mon, 2 Nov 2015, Karl Dahlke wrote:

> One of my science queries led me to this page,
> http://hypertextbook.com/facts/2000/StephanieLum.shtml
> run with db3 and edbrowse stops at
> execute addthis_widget.js at 1
> js never returns, seems to run forever, chewing up cycles in the process.
> This is, sadly, one of those javascripts that Chris refers to as dog vomit,
> so not clear at all how to track this one down.
>
> Karl Dahlke
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
>

--------
Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists

[Edbrowse-dev] Red Hot

[Karl Dahlke]

Always investigate every mystery.
It's always trying to tell us something.

This infinite loop is caused by:

for(;e.firstChild;)
e.removeChild(e.firstChild);

Clearing all the nodes out from under e, simple enough,
but I implemented firstChild as a function, e.firstChild(),
so e.firstChild is always true.
Oops.
firstChild is a property, a magic property
that always means this.childNodes[0].
Wow, how can we implement that?
Well there's a way, and it doesn't require native code, thank heaven,
but I will need to muck with all the firstChilds in starrtwindow.js,
so I think I'll hold off until Kevin sends me his next cloneNode.

Karl Dahlke

Re: [Edbrowse-dev] Red Hot

[Adam Thompson]

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

On Tue, Nov 03, 2015 at 03:02:05AM -0500, Karl Dahlke wrote:
> Always investigate every mystery.
> It's always trying to tell us something.
> 
> This infinite loop is caused by:
> 
> for(;e.firstChild;)
> e.removeChild(e.firstChild);
> 
> Clearing all the nodes out from under e, simple enough,
> but I implemented firstChild as a function, e.firstChild(),
> so e.firstChild is always true.
> Oops.
> firstChild is a property, a magic property
> that always means this.childNodes[0].
> Wow, how can we implement that?
> Well there's a way, and it doesn't require native code, thank heaven,
> but I will need to muck with all the firstChilds in starrtwindow.js,
> so I think I'll hold off until Kevin sends me his next cloneNode.

Excellent, thanks for spotting this Karl.
I'm interested to know how one implements such magic,
will be fascinated to see the code.

Cheers,
Adam.
PS: can/should we implement a timeout for these calls pending proper
asynchronicity?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] Red Hot

[Karl Dahlke]

> I'm interested to know how one implements such magic,

It's something like this.
This is for any div node . firstchild.

Object.defineProperty(Div.prototype, "firstChild", {
get: function() { return this.childNodes[0]; }
});

Karl Dahlke

Re: [Edbrowse-dev] Red Hot

[Adam Thompson]

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

On Tue, Nov 03, 2015 at 03:34:52AM -0500, Karl Dahlke wrote:
> > I'm interested to know how one implements such magic,
> 
> It's something like this.
> This is for any div node . firstchild.
> 
> Object.defineProperty(Div.prototype, "firstChild", {
> get: function() { return this.childNodes[0]; }
> });
> 

Ah ok, didn't know js supported this kind of thing, that's useful to know.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] Red Hot

[Adam Thompson]

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

On Mon, Nov 02, 2015 at 10:51:21PM -0800, Kevin Carhart wrote:
> More possible clues to what this is or isn't caused by:
> 
> When I run this page in the i686 static build, it loads immediately.

That's interesting, what does db3 show, i.e.
is it showing the js runnin successfully or erroring out at some stage?

> When I run it in my ancient 3.3.1, it is slow but eventually completes.

Wow, ok, that's a first for me, i.e.
a page which loads with old edbrowse but not new edbrowse.

I also can reproduce the problem and hitting ^c to kill the (apparently
infinitely) loading page kills my edbrowse-js process.
I'm thinking that what's happening here is they're using some code
(ajax or similar) which is designed to run in the background all the time.
In Edbrowse, because we have synchronous calls,
this just blocks the entire process.
This is backed up by the fact that attaching gdb to the running edbrowse-js
process I can see that it's stuck in the guts of the js vm (no debugging
symbols unfortunately so can't do much else there).
Also an:
ltrace -C -S -p
on the process shows that the process is busily calling various js functions
(they scrolled off the screen, but when I've more time I can work through them),
so I suspect the js has gone infinite somewhere.

For those who don't know (I didn't until I got into server debugging at work),
ltrace is like strace but for library calls.
The options above do name demangling,
allow tracing of system as well as library calls and attach to the pid.
I could also set it up to trace children and run on edbrowse itself, but I'm not sure how useful that would be for this issue.

Is it worth passing the debug level through to the edbrowse-js process somehow, may be output a log file?

Regards,
Adam.
> 
> 
> On Mon, 2 Nov 2015, Karl Dahlke wrote:
> 
> >One of my science queries led me to this page,
> >http://hypertextbook.com/facts/2000/StephanieLum.shtml
> >run with db3 and edbrowse stops at
> >execute addthis_widget.js at 1
> >js never returns, seems to run forever, chewing up cycles in the process.
> >This is, sadly, one of those javascripts that Chris refers to as dog vomit,
> >so not clear at all how to track this one down.
> >
> >Karl Dahlke
> >_______________________________________________
> >Edbrowse-dev mailing list
> >Edbrowse-dev@lists.the-brannons.com
> >http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
> >
> 
> --------
> Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] Red Hot

[Kevin Carhart]

Well, Karl has found this now so it's moot, but if you'd like to know what 
db3 shows, here are the last several:

execute StephanieLum.shtml at 36
execution complete
java source http://s7.addthis.com/js/300/addthis_widget.js#pubid=elert
content text/javascript
http code 200
execute addthis_widget.js at 1
addthis_widget.js line 5: TypeError: e.removeChild is not a function
execution complete
TypeError: a.contentWindow is undefined
anchorSwap 10
anchors unframed
whitespace combined

>> When I run it in my ancient 3.3.1, it is slow but eventually completes.
>
> Wow, ok, that's a first for me, i.e.
> a page which loads with old edbrowse but not new edbrowse.

I'm going to rescind.  I'm really not sure.... it's so idiosyncratic and 
mucked with, it's like frankenbrowse.  It's not helpful as a datapoint 
since whatever made it work isn't transferrable so on we go into the 
future!

> ltrace is like strace but for library calls.

Ah, I knew about strace and ptrace.

Kevin