edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Kevin Carhart <kevin@carhart.net>
To: Karl Dahlke <eklhad@comcast.net>
Cc: edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] jquery v2 and an interesting seg fault
Date: Fri, 4 Dec 2015 13:10:06 -0800 (PST)	[thread overview]
Message-ID: <alpine.LRH.2.03.1512041248370.26352@carhart.net> (raw)
In-Reply-To: <20151104092453.eklhad@comcast.net>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2765 bytes --]


I found out some interesting things about compiling later versions of
jquery.
Apparently what separates jquery 1.9 support from support for the latest 
is not very much.  I found that I could even get 2.1.4 to compile
if I add three more initializations to the startwindow file:

document.nodeType = 9;
document.implementation = {};
document.location = {};

Apparently these things need to be there for versions of
jquery from 1.10 and upwards to work.

In this thread beginning at around line 165, the Sizzle developer
lays out what is the minimum DOM implementation to "load Sizzle
without exceptions - invocation being another story though".

https://github.com/jquery/sizzle/issues/343

So I'm comparing what we already have with what this person
says is the minspec, and that's how I arrive at needing
nodeType, implementation and location, at least to start,
and get over the catch-22's.

I added these three lines to startwindow and recompiled.
It appears that a lot of "Can't load jquery" runtimes went away.

If these three lines are all benefit and no drawback, I'd
like to send a patch and get them in.  However, I tested on
fanfiction.net, to take a popular scenario, and I got a
seg fault with the following backtrace:

---

(gdb) bt

#0  0x000000000042b7ff in javaSetsLinkage (after=1 '\001', type=114 'r',
     p_j=0x7f8ea71588e0, rest=0x1456250 "div 0x7f8ea7158910,textarea 0x0, 
")
     at html.c:2352

#1  0x0000000000427366 in runScriptsPending () at html.c:663

#2  0x00000000004276c0 in htmlParse (
     buf=0x14417f0 "\264r\304\037D\005\267\030\022\333\061²Uz\231Æ
\224t\225\t6J\325*?\361K\032#\350\061c\341\260\037\336\364\363\034p%\270\241\320K\303t\031D[\363\002\202W+\016w\031\312,{\213\341\034cK\305M\334*2Øc\334kK\337\070\266\311\353\345\223.W\302\313\326\025f«;\260\267\242Qt\325\344\301Ds\274H\201\275\204e\255\311\060^\266\304\324Z\307\362\251\071Z:\250mF\363$2\024h\215\242\017\221\030\r\274\210\226׳\036\274\001", 
remote=1) at html.c:750

#3  0x00000000004153bf in browseCurrentBuffer () at buffers.c:5401

#4  0x00000000004146b1 in runCommand (
     line=0x698b82 <line.8810+2> "http://fanfiction.net") at buffers.c:5065

#5  0x0000000000414e05 in edbrowseCommand (
     line=0x698b80 <line.8810> "b http://fanfiction.net", script=0 '\000')
     at buffers.c:5237

#6  0x0000000000406946 in main (argc=0, argv=0x7ffcb18e6a30) at 
main.c:1372

(gdb) q

---

I hope the included backtrace is legible.  So my question, to
put it concisely, is can you tell just by reviewing the
backtrace what is going wrong with javaSetsLinkage?  It
appears that javaSetsLinkage is encountering a long series
of escaped characters or binary.  I wonder if I'm causing
this with my 3 new initializations, or reaching an existing
bug.

thanks
Kevin

  reply	other threads:[~2015-12-04 21:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02 18:11 [Edbrowse-dev] 3.6.0? Chris Brannon
2015-12-02 20:01 ` Karl Dahlke
2015-12-03  1:59   ` Kevin Carhart
2015-12-03  2:42     ` Chris Brannon
2015-12-03  3:13       ` Kevin Carhart
2015-12-03  4:52         ` Karl Dahlke
2015-12-04  1:05           ` Kevin Carhart
2015-12-04 14:24             ` Karl Dahlke
2015-12-04 21:10               ` Kevin Carhart [this message]
2015-12-04 22:11                 ` [Edbrowse-dev] jquery v2 and an interesting seg fault Karl Dahlke
2015-12-04 22:28                   ` Kevin Carhart
2015-12-05  9:12                     ` [Edbrowse-dev] javascript() in timer side effects Kevin Carhart
2015-12-05 14:39                       ` Karl Dahlke
2015-12-06  0:19                         ` Kevin Carhart
2015-12-06  0:26                           ` Karl Dahlke
2015-12-06  2:48                             ` Kevin Carhart
2015-12-06 11:38                               ` Adam Thompson

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=alpine.LRH.2.03.1512041248370.26352@carhart.net \
    --to=kevin@carhart.net \
    --cc=edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /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).