128273 - Various crashes showing up again in Trunk, M098, N621 at [@ js_Interpret ]

Status: RESOLVED DUPLICATE of bug 132216

(Core :: XUL, defect)

Description

[greer]

Bug 106820 handled the infinite recursion issue at this signature, but still
the Talkback reports are showing tons of crashes at this signature. (Keeping
component from bug 106820, but wll probably end up somewhere else.)

   The user comments are wildy varying from launching browser/mail from the tray
icon to viewing PDF files and simple surfing. In the hopes of finding something,
I will include the user comments from the most recent releases (N621 - 665, M098
- 273, Trunk - 85) in an attachment below. This is a huge set of problems with
no clear direction. 

   The comments for each release are followed by internal folks who have crashed
at this signature, that may be helpful.

Stack Trace: 

         js_Interpret   [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 1226]
         js_Execute     [d:\builds\seamonkey\mozilla\js\src\jsinterp.c  line 970]
         JS_ExecuteScript       [d:\builds\seamonkey\mozilla\js\src\jsapi.c 
line 3229]
         nsJSContext::ExecuteScript
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp  line 824]
         nsXULDocument::ExecuteScript
[d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp  line 6207]
         nsXULDocument::LoadScript
[d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp  line 5998]
         nsXULDocument::ResumeWalk
[d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp  line 5777]
         nsXULDocument::OnStreamComplete
[d:\builds\seamonkey\mozilla\content\xul\document\src\nsXULDocument.cpp  line 6165]
         nsStreamLoader::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamLoader.cpp  line 163]
         nsJARChannel::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\jar\src\nsJARChannel.cpp  line 614]
         nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp  line 213]
         PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c 
line 591]
         PL_ProcessPendingEvents       
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line
524]
         _md_EventReceiverProc 
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1072]
         nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 308]
         main1  [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp 
line 1301]
         main   [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp 
line 1628]
         WinMain       
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line 1646]
         WinMainCRTStartup()
         KERNEL32.DLL + 0xd326 (0x77e8d326)
 
        Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsinterp.c line :1226

Comment 1

[greer]

Attachment: Breakdown of unique stacks for js_Interpret from Win Trunk reports

Comment 2

[greer]

Attachment: Comments from crashes on M097/8, N621 and Trunk

Comment 3

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

One interesting question is why all of these reports are Windows-only.  I had
been thinking it might have been due to the memory flusher code.  However, that
code wasn't hooked up.

But now I'm wondering whether it might have something to do with turbo.  (One of
the user comments mentions turbo.)  I don't quite see how, though.  Then again,
I'm not exactly sure what state things are supposed to be in when we're in the
"shut down" state in turbo, especially now that profile-switching is supported.

Comment 4

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

Er, wait.  There are some Linux stacks in attachment 71888 [details].  Never mind. 
Although the Linux stacks could be a different stack -- they show ups a black in
the detailed crash reports.

Comment 5

[David Bradley]

Attachment: Stack Trace of a crash

I crashed in this area. I had just hit ctrl-m. In this case, the script object
that was passed into nsJSContext::ExecuteScript, the code member is set to 2.
This causes a crash at line 1269 when it tries to dereference it: op =
(JSOp)*pc;

I do see crashes in Talkback at 1269 as well. It could be the they stem from
the same cause and it just depends on how bad the script object has been
corrupted. Is the script object getting collected by accident?

Dump of fp->script:

code = 0x00000002
length = 0x04072438
main = 0x0
version = 0x44fcc28
atomMap = { vector = 0x0, length = 0x5 }
filename = 0x023f3858 ""
lineno = 0x0
depth = 0x00050007
notes = 0x00080105 (Invalid address)
trynotes = 0x00ebfa28 { 
    start = 0x02477c40, 
    length = 0xa6983d6a, 
    catchStart = 0x00ebbf74
    }
principals = 0x00ec59e0 {
    codebase = 0x0
    getPrincipalArray = 0x65a64523
    globalPrivilegesEnabled = 0x00ebc14c
    refcount = 0x0
    destroy = 0x02
    }
fun = 0x0
thisp = 0x031813c0 (Looks valid)
argc = 0x0
argv = 0x0
rval = 0x80000001
nvars = 0x0
vars = 0x0
down = 0x0
annotation = 0x0
scopeChain = 0x031813c0 (looks valid)
pc = 0x00000002
sp = 0x05a20050
spbase = 0x05a20050
sharpDepth = 0x0
sharpArray = 0x0
flags = 0x0
domainNext = 0x0

Comment 6

[David Bradley]

I looked at the talkback data for the crash at line 1226. It's actually crashing
during the assignment of currentVersion = script->version. Optimization throws
things off a bit. So these two do look to be the same problem. There's something
wrong with the script object being executed, either it was corrupted, or more
likely, collected and the memory is being reused.

Comment 7

[David Bradley]

I think this and bug 127047 are probably different symptoms of the same problem

Comment 8

[Jay Patel [:jay]]

Adding topcrash, qawanted keywords and marking dup of bug 132216 per Comment #7.
 This is simply for future reference and to get this off the radar.  If this is
not a dup, please feel free to reopen.

*** This bug has been marked as a duplicate of 132216 ***