[Edbrowse-dev] seg fault what?

[Edbrowse-dev] seg fault what?

[Karl Dahlke]

Even more mysterious.
I have whittled the file down to about 3200 lines,
self contained, does not reference any other websites,
and still seg fault.

www.eklhad.net/nyt

But, remove any of the blank lines at 218 and it works.
In fact you can remove almost any line,
first line last line etc,
and it works again.
I gotta take a break; I don't get it.
How can removing a blank line change anything?

Karl Dahlke

Re: [Edbrowse-dev] seg fault what?

[Chris Brannon]

I can't reproduce with your file in any version that I have, but I think
I've found a similar test case.
Visit www.youtube.com with js enabled.  Search for Popular (with
/Popular) and click on the link.  It always segfaults for me, with
several versions: edbrowse from master built against
spidermonkey 1.8.5, code from Adam's git repository built against
spidermonkey 24.0, and even edbrowse 3.4.9 built against spidermonkey
1.8.5.
I also managed to reproduce the crash under valgrind, and here's what I
found.  I'm posting two logs, one made with edbrowse from master, the
other made with edbrowse from Adam's repo.  Notice that they look
suspiciously similar.  For ease of navigation, the logs are enclosed in
<log> and </log>


<log>
(With edbrowse built against spidermonkey 1.8.5):
Invalid read of size 8
   at 0x565F3AE: JS_NewObject (in /usr/lib64/libmozjs185.so.1.0.0)
   by 0x42F80F: domLink (jsdom.c:1185)
   by 0x424092: encodeTags (html.c:1621)
   by 0x424A50: htmlParse (html.c:2134)
   by 0x40E1D7: browseCurrentBuffer (buffers.c:4837)
   by 0x410068: runCommand (buffers.c:4446)
   by 0x412E2F: edbrowseCommand (buffers.c:4621)
   by 0x4068C9: main (main.c:1303)
 Address 0x1000045ba is not stack'd, malloc'd or (recently) free'd


Process terminating with default action of signal 11 (SIGSEGV)
 Access not within mapped region at address 0x1000045BA
   at 0x565F3AE: JS_NewObject (in /usr/lib64/libmozjs185.so.1.0.0)
   by 0x42F80F: domLink (jsdom.c:1185)
   by 0x424092: encodeTags (html.c:1621)
   by 0x424A50: htmlParse (html.c:2134)
   by 0x40E1D7: browseCurrentBuffer (buffers.c:4837)
   by 0x410068: runCommand (buffers.c:4446)
   by 0x412E2F: edbrowseCommand (buffers.c:4621)
   by 0x4068C9: main (main.c:1303)
</log>

<log>
(With edbrowse built against spidermonkey 24.0):
Invalid read of size 8
   at 0x571EA32: js::GCMarker::drainMarkStack(js::SliceBudget&) (Heap.h:687)
   by 0x5808C14: IncrementalCollectSlice(JSRuntime*, long, JS::gcreason::Reason, js::JSGCInvocationKind) (jsgc.cpp:3779)
   by 0x580A960: GCCycle(JSRuntime*, bool, long, js::JSGCInvocationKind, JS::gcreason::Reason) (jsgc.cpp:4422)
   by 0x580AD7F: Collect(JSRuntime*, bool, long, js::JSGCInvocationKind, JS::gcreason::Reason) [clone .part.222] (jsgc.cpp:4558)
   by 0x580B1D8: void* js::gc::ArenaLists::refillFreeList<(js::AllowGC)1>(js::ThreadSafeContext*, js::gc::AllocKind) (jsgc.cpp:1467)
   by 0x588BC46: JSFlatString* js_NewStringCopyN<(js::AllowGC)1>(JSContext*, unsigned short const*, unsigned long) (jsgcinlines.h:541)
   by 0x57C45DE: js::Atomize(JSContext*, char const*, unsigned long, js::InternBehavior) (jsatom.cpp:306)
   by 0x57AC8E1: DefineProperty(JSContext*, JS::Handle<JSObject*>, char const*, JS::Value const&, JSPropertyOpWrapper const&, JSStrictPropertyOpWrapper const&, unsigned int, unsigned int, int) (jsapi.cpp:3718)
   by 0x57ACCA9: JS_DefineProperty(JSContext*, JSObject*, char const*, JS::Value, int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, JS::MutableHandle<JS::Value>), int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, int, JS::MutableHandle<JS::Value>), unsigned int) (jsapi.cpp:3734)
   by 0x43A9E1: domLink (jsdom.cpp:1263)
   by 0x429E55: encodeTags (html.c:1447)
   by 0x42C0CB: htmlParse (html.c:2134)
 Address 0xfc0b0 is not stack'd, malloc'd or (recently) free'd


Process terminating with default action of signal 11 (SIGSEGV)
 Access not within mapped region at address 0xFC0B0
   at 0x571EA32: js::GCMarker::drainMarkStack(js::SliceBudget&) (Heap.h:687)
   by 0x5808C14: IncrementalCollectSlice(JSRuntime*, long, JS::gcreason::Reason, js::JSGCInvocationKind) (jsgc.cpp:3779)
   by 0x580A960: GCCycle(JSRuntime*, bool, long, js::JSGCInvocationKind, JS::gcreason::Reason) (jsgc.cpp:4422)
   by 0x580AD7F: Collect(JSRuntime*, bool, long, js::JSGCInvocationKind, JS::gcreason::Reason) [clone .part.222] (jsgc.cpp:4558)
   by 0x580B1D8: void* js::gc::ArenaLists::refillFreeList<(js::AllowGC)1>(js::ThreadSafeContext*, js::gc::AllocKind) (jsgc.cpp:1467)
   by 0x588BC46: JSFlatString* js_NewStringCopyN<(js::AllowGC)1>(JSContext*, unsigned short const*, unsigned long) (jsgcinlines.h:541)
   by 0x57C45DE: js::Atomize(JSContext*, char const*, unsigned long, js::InternBehavior) (jsatom.cpp:306)
   by 0x57AC8E1: DefineProperty(JSContext*, JS::Handle<JSObject*>, char const*, JS::Value const&, JSPropertyOpWrapper const&, JSStrictPropertyOpWrapper const&, unsigned int, unsigned int, int) (jsapi.cpp:3718)
   by 0x57ACCA9: JS_DefineProperty(JSContext*, JSObject*, char const*, JS::Value, int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, JS::MutableHandle<JS::Value>), int (*)(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, int, JS::MutableHandle<JS::Value>), unsigned int) (jsapi.cpp:3734)
   by 0x43A9E1: domLink (jsdom.cpp:1263)
   by 0x429E55: encodeTags (html.c:1447)
   by 0x42C0CB: htmlParse (html.c:2134)
</log>

-- Chris

Re: [Edbrowse-dev] seg fault what?

[Adam Thompson]

On Thu, Jan 23, 2014 at 10:28:47AM -0800, Chris Brannon wrote:
> I can't reproduce with your file in any version that I have, but I think
> I've found a similar test case.

Out of interest, what's your machine spec?
On my machine (Debian unstable, amd athlon 64 with 1 gb ram and edbrowse built
against a debug build of SpiderMonkey 24) I can reliably reproduce this bug.
I really am struggling to understand exactly what's going wrong,
but the log looks suspiciously like gc issues.

The annoying part of this is that I can't safely root a NULL pointer (it
crashed every time I tried until I removed the rooting,
dispite what the docs say),
which makes correctly rooting some of our global pointers awkward.

Cheers,
Adam.

Re: [Edbrowse-dev] seg fault what?1

[Adam Thompson]

On Fri, Jan 24, 2014 at 10:31:40AM +0000, Adam Thompson wrote:
> On Thu, Jan 23, 2014 at 10:28:47AM -0800, Chris Brannon wrote:
> > I can't reproduce with your file in any version that I have, but I think
> > I've found a similar test case.

Ok, latest news on this (sorry for the multiple posts in 2 hours),
but in mozjs 24, I discovered in js/CallArgs.h (I think case is correct)
that we need to rewrite *all* our functions which are defined as js natives (i.e.
c++ functions which can be called by javascript) to use the new CallArgs api.
This is to do with the new moving GC.
This will take a while, but once I work out how this works it's just going to be repetative coding.

Cheers,
Adam.
PS: I really wish SpiderMonkey had a more stable api.

Re: [Edbrowse-dev] seg fault what?

[Adam Thompson]

On Fri, Jan 24, 2014 at 08:29:31AM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Out of interest, what's your machine spec?
> 
> It's an AMD64 with 4 gigs of RAM, running Gentoo.  Spidermonkey is built
> with -O2 -g -ggdb in CFLAGS.

Ok, I guess one thing could be that you're not triggering gc as regularly as my
machine, or other library differences. I used the SpiderMonkey provided configure
script with --disable-optimize and --enable-debug options (disabled
optimisation so I could actually get sane gdb output when the
Spidermonkey lib blows up).

I've also just (hopefully) pushed commits rewriting most of our js native
functions to use the new CallArgs api.
I'm not sure if this has squashed any of the problems we've been finding but we
need to do it anyway.

Cheers,
Adam.