1037887 - webgl google maps crashes due to nsXMLHttpRequest management of array buffers

Status: RESOLVED DUPLICATE of bug 1030667

(Core :: DOM: Core & HTML, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I suspect this is likely a duplicate of a bug that I don't have access to, but I just spent an hour debugging it, and I'm not sure if it's known that it's happening in the wild (on a prominent page, too).

Steps to reproduce:
 1. go to about:config, and enable "layers.acceleration.force-enabled"
 2. restart the browser
 3. load https://www.google.com/maps/preview/?force=webgl
 4. use the button in the lower left to switch to Satellite ("Earth") view
 5. switch to tilt mode using the button above the +/- and below the compass in the lower right
 6. pan around a bit

Actual results: crash

(I'm running a self-built mozilla-central x86-64 Linux debug build.)

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: valgrind's explanation of the problem

(Annoyingly, I had to run valgrind with --smc-check=all, which I thought an --enable-valgrind was supposed to save me from.)

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Making the obvious change to ArrayBufferBuilder::setCapacity (i.e., adding "&& aNewCap") moves the problem to a JS assertion elsewhere, though:

Assertion failure: contents, at /home/dbaron/builds/ssd/mozilla-central/mozilla/js/src/vm/ArrayBufferObject.cpp:1087

#5  <signal handler called>
#6  0x00007fcd06d3eb18 in JS_NewArrayBufferWithContents (cx=<optimized out>, 
    nbytes=<optimized out>, contents=0x0)
    at /home/dbaron/builds/ssd/mozilla-central/mozilla/js/src/vm/ArrayBufferObject.cpp:1087
#7  0x00007fcd05c44dbe in mozilla::ArrayBufferBuilder::getArrayBuffer (
    this=0xe1ea928, aCx=0xe7db30)
    at /home/dbaron/builds/ssd/mozilla-central/mozilla/content/base/src/nsXMLHttpRequest.cpp:4046
#8  0x00007fcd05c50c95 in nsXMLHttpRequest::GetResponse (this=0xe1ea730, 
    aCx=0xe7db30, aResponse=..., aRv=...)
    at /home/dbaron/builds/ssd/mozilla-central/mozilla/content/base/src/nsXMLHttpRequest.cpp:981
#9  0x00007fcd05c50f17 in nsXMLHttpRequest::GetResponse (this=<optimized out>, 
    aCx=<optimized out>, aResult=...)
    at /home/dbaron/builds/ssd/mozilla-central/mozilla/content/base/src/nsXMLHttpRequest.cpp:942
#10 0x00007fcd05aae648 in (anonymous namespace)::EventRunnable::PreDispatch (
    this=0x75a8670, aCx=0xe7db30, aWorkerPrivate=0x2a415c0)
    at /home/dbaron/builds/ssd/mozilla-central/mozilla/dom/workers/XMLHttpRequest.cpp:1179

Comment 4

[Jesse Ruderman]

That surprises me. I thought bug 1030667 indicated that ASan-on-Linux had a different realloc behavior than normal Linux.

Comment 5

[Jeff Walden [:Waldo]]

Self-built build would link against glibc, which has the broken realloc(..., 0) does a free behavior.

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Only because I --enable-trace-malloc, but yes.