Crash when creating new Response object.

RESOLVED INVALID

Status

()

Core
DOM: Core & HTML
RESOLVED INVALID
a year ago
a year ago

People

(Reporter: djvj, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
Seeing the following crash when creating a new Response object:

        response.respondWith(new Response(resp, {
            headers: { 'Content-Type': 'text/html' }
        }));
     
     
    Program received signal SIGSEGV, Segmentation fault.
    0x00007fffe6843e72 in mozilla::dom::Headers::Headers (this=0x7fffc4ce23c0, aOwner=0x7fffd5058900, aInternalHeaders=0x7fffc54ca3c0)
        at /home/kvijayan/Checkouts/larch/BUILD-DEBUG64/dist/include/mozilla/dom/Headers.h:52
    52          MOZ_ASSERT(aInternalHeaders->Guard() == HeadersGuardEnum::Immutable ||
    (gdb) p aInternalHeaders->Guard()
    $1 = mozilla::dom::HeadersGuardEnum::None
    (gdb) bt 10
    #0  0x00007fffe6843e72 in mozilla::dom::Headers::Headers (this=0x7fffc4ce23c0, aOwner=0x7fffd5058900, aInternalHeaders=0x7fffc54ca3c0)
        at /home/kvijayan/Checkouts/larch/BUILD-DEBUG64/dist/include/mozilla/dom/Headers.h:52
    #1  0x00007fffe68380ca in mozilla::dom::Headers::Create (aGlobal=0x7fffd5058900, aInit=..., aRv=...)
        at /home/kvijayan/Checkouts/larch/dom/fetch/Headers.cpp:69
    #2  0x00007fffe6840452 in mozilla::dom::Response::Constructor (aGlobal=..., aBody=..., aInit=..., aRv=...)
        at /home/kvijayan/Checkouts/larch/dom/fetch/Response.cpp:191
    #3  0x00007fffe5d4d34e in mozilla::dom::ResponseBinding::_constructor (cx=0x7fffcb915c00, argc=2, vp=0x7fffdac881b8)
        at /home/kvijayan/Checkouts/larch/BUILD-DEBUG64/dom/bindings/ResponseBinding.cpp:1020
    #4  0x00007fffe9a7132a in js::CallJSNative (cx=0x7fffcb915c00,
        native=0x7fffe5d4cac5 <mozilla::dom::ResponseBinding::_constructor(JSContext*, unsigned int, JS::Value*)>, args=...)
        at /home/kvijayan/Checkouts/larch/js/src/jscntxtinlines.h:235
    #5  0x00007fffe9a71464 in js::CallJSNativeConstructor (cx=0x7fffcb915c00,
        native=0x7fffe5d4cac5 <mozilla::dom::ResponseBinding::_constructor(JSContext*, unsigned int, JS::Value*)>, args=...)
        at /home/kvijayan/Checkouts/larch/js/src/jscntxtinlines.h:268
    #6  0x00007fffe9a4f2dd in InternalConstruct (cx=0x7fffcb915c00, args=...) at /home/kvijayan/Checkouts/larch/js/src/vm/Interpreter.cpp:565
    #7  0x00007fffe9a4f440 in ConstructFromStack (cx=0x7fffcb915c00, args=...) at /home/kvijayan/Checkouts/larch/js/src/vm/Interpreter.cpp:592
    #8  0x00007fffe9a5e059 in Interpret (cx=0x7fffcb915c00, state=...) at /home/kvijayan/Checkouts/larch/js/src/vm/Interpreter.cpp:2799
    #9  0x00007fffe9a4e877 in js::RunScript (cx=0x7fffcb915c00, state=...) at /home/kvijayan/Checkouts/larch/js/src/vm/Interpreter.cpp:426
    (More stack frames follow...)
    (gdb)
Probably a bogus assert.  I'll check.  Thanks!
Flags: needinfo?(bkelly)
This is due to assertions that I added on the larch branch, and that I think we should port to m-c. Without the assertions it is very easy to accidentally create a Request object which enables a webpage to set arbitrary headers, such as 'Host', which would be very bad.
Marking this particular bug invalid for now.  I'd be interested in seeing the patch to add these assertions to trunk, though.

Note, however, as they are now these assertions are wrong.  This is valid js for content script:

  var h = new Headers({'foo': 'bar');
  // h's guard is None

See here:

  https://fetch.spec.whatwg.org/#dom-headers

I think what you are really asking for is an assertion that a Request or Response never has a headers object directly associated with it that has a guard "None".

While the stack may look like Response is use guard "None", its actually just creating a temporary Headers object to unwrap the dictionary using the Headers Constructor.  It then fills into the real Headers object that uses guard "Response".
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(bkelly)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.