581279 - Crash [@ NS_LogCOMPtrAddRef_P] when going back to previous page

Status: RESOLVED DUPLICATE of bug 559200

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

Description

[Josh Matthews [:jdm]]

Attachment: Backtrace

This is a fennec crash I found while playing around and is completely reproducible for me.

STR:
* http://www.reddit.com/r/programming/search?q=ssh
* click on "Useful things you can make SSH do"
* press escape
* crash hard with attached stack

Seen in the console before the child process crashes:

###!!! ASSERTION: Got data on wrong stream.: 'mRequest == aRequest', file /home/t_mattjo/src/firefox/mobilebase/parser/html/nsHtml5StreamParser.cpp, line 719
###!!! ASSERTION: DoDataAvailable called when stream not open.: 'STREAM_BEING_READ == mStreamState', file /home/t_mattjo/src/firefox/mobilebase/parser/html/nsHtml5StreamParser.cpp, line 657
###!!! ASSERTION: Got data on wrong stream.: 'mRequest == aRequest', file /home/t_mattjo/src/firefox/mobilebase/parser/html/nsHtml5StreamParser.cpp, line 719
###!!! ASSERTION: Got data on wrong stream.: 'mRequest == aRequest', file /home/t_mattjo/src/firefox/mobilebase/parser/html/nsHtml5StreamParser.cpp, line 719
###!!! ASSERTION: Got Stop on wrong stream.: 'mRequest == aRequest', file /home/t_mattjo/src/firefox/mobilebase/parser/html/nsHtml5StreamParser.cpp, line 640

The channel in the stack is really weird - it's dead and shouldn't exist in IPDL's eyes to receive messages.  The necko child is corrupted and brings down gdb if I try to output it.  Something is really screwy here.

I'm not convinced this is an HTTP channel bug by any means, but it's a good place to start.

Comment 1

[Josh Matthews [:jdm]]

Attachment: Valgrind parser errors

I caught it under valgrind.  Looks like something funky is going on with the parser.

Comment 2

[Josh Matthews [:jdm]]

Also see this assertion after the stream ones:

###!!! ASSERTION: DoContent returned no listener?: 'abort || m_targetStreamListener', file /home/t_mattjo/src/firefox/mobilebase/uriloader/base/nsURILoader.cpp, line 776

Comment 3

[Josh Matthews [:jdm]]

Something's very wrong here.  I got this:

==18128== 
==18128== More than 10000000 total errors detected.  I'm not reporting any more.
==18128== Final error counts will be inaccurate.  Go fix your program!
==18128== Rerun with --error-limit=no to disable this cutoff.  Note
==18128== that errors may occur in your program without prior warning from
==18128== Valgrind, because errors are no longer being displayed.
==18128== 

and the summary of the child process:

==18128== 
==18128== For counts of detected and suppressed errors, rerun with: -v
==18128== ERROR SUMMARY: 10000000 errors from 2 contexts (suppressed: 136 from 11)

But I only saw the ones posted so far.

Comment 4

[Josh Matthews [:jdm]]

All the valgrind errors point to the parser at this point, so I'm switching the component.

Comment 5

[Josh Matthews [:jdm]]

I've done some more analysis.  This looks like the same issue as bug 559200, but now we've got nsXMLHttpRequest::Send processing events so the parser ends up having OnDataAvailable being called before OnStartRequest finishes.

Comment 6

[Josh Matthews [:jdm]]

Attachment: Problematic backtrace

Here's the stack that shows the problem.  In frame 40, the HttpChannelChild receives an OnStartRequest and triggers the corresponding listener.  This ends up firing an event which executes a JS script (http://mediacdn.disqus.com/1047/javascript/httpjson.js) which fires off a sync XMLHttpRequest, which ends up firing the OnDataAvailable event for the original HttpChannel before OnStartRequest has finished.

Comment 7

[Jason Duell]

Going to be fixed by necko IPDL buffering.