Bugzilla

Comment 2

•

24 years ago

I'm guessing at a common theme here: Security is checking to see if a page 
calling a function has the right to do so. This can be triggered by an
event, as we see in the call stack reported above. Note that the stack
frames pass through libcaps.so just before we crash - 


I took a quick look through TalkBack reports with JS_GetFunctionObject 
as the signature. For example, here is one for NN6.5 from 2001-02-27:

http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=92&cp=1&ck1=
SStack+crawl+signature&cd1=%25JS%5FGetFunctionObject%25&co1=like&bbid=27029787

Incident ID: 27029787
Trigger Type: Program Crash 
Trigger Reason: Access violation 
Call Stack: (Signature = JS_GetFunctionObject f98b67ef) 


JS_GetFunctionObject   [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3450]
nsScriptSecurityManager::GetFunctionObjectPrincipal   
[d:\builds\seamonkey\mozilla\caps\src\nsScriptSecurityManager.cpp, line 906]
nsScriptSecurityManager::CheckFunctionAccess 
[d:\builds\seamonkey\mozilla\caps\src\nsScriptSecurityManager.cpp, line 614]
nsJSContext::CallEventHandler  
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 936]
nsJSDOMEventListener::HandleEvent   
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSDOMEventListener.cpp, line 92]
nsEventListenerManager::HandleEventSubType   
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 
839]
nsEventListenerManager::HandleEvent  
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 
1422]
GlobalWindowImpl::HandleDOMEvent  
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 575]
DocumentViewerImpl::LoadComplete   
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 717]
nsDocShell::EndPageLoad     
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2656]
nsWebShell::EndPageLoad    
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 992]
nsDocShell::OnStateChange   
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2574]
nsWebShell::OnStateChange   
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 954]
nsDocLoaderImpl::FireOnStateChange   
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 1309]
nsDocLoaderImpl::doStopDocumentLoad   
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 736]     
nsDocLoaderImpl::DocLoaderIsEmpty  
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 632]
nsDocLoaderImpl::OnStopRequest  
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 564]

                     etc. 
                     etc.

Assignee: rogerl → mstoltz

Status: UNCONFIRMED → NEW

Component: Javascript Engine → Security: General

Ever confirmed: true

QA Contact: pschwartau → ckritzer

Comment 3

•

24 years ago

Mitch explained this possibility to me, and he will take a look at it. 
Also cc'ing Brendan, in case he feels a JS Engine issue may be involved -

Comment 4

•

24 years ago

Just found out from jpatel that this is currently our #1 topcrasher:


Crash Analysis from Seamonkey Trunk builds since 2001021800

Look here for bugs ready filed on these crashes:
  http://bugzilla.mozilla.org/buglist.cgi?keywords=topcrash&order=bugs.bug_id

Look here for Details crash data as web page
 http://www.mozilla.org/projects/seamonkey/reports/ns6analysis.html


 Total blackboxes in this sample:     1010
 Total unique users:      352
 MTBF For these builds is estimated at 2.983113 hours,
 based on 974 reports and 2905.552222 hours of user testing
 from testers that have crashed and reported problems.
  (dev. builds tend to have low MTBF)


 Top crashes 
 Count - Area
  68 JS_GetFunctionObject
  48 nsCacheManager::NoteDormant
  40 libmozjs.so
  32 JS_GetPrivate
  31 nsNNTPProtocol::SendFirstNNTPCommand
  29 nsTableFrame::GetFrameAtOrBefore
  28 MSVCRT.DLL
  25 xpcom.dll
  24 free
  23 js_EmitTree
  21 nsVoidArray::RemoveElement
  19 msgcompo.dll
  17 nsQueryInterface::operator
  15 libxpcom.so
  15 il_flush_image_data
  15 gkhtml.dll
  14 nsCOMPtr_base::assign_with_AddRef
  13 0x00000000
  12 nsHTTPChannel::GetSecurityInfo
  11 morkRowObject::CloseRowObject
  10 ImageConsumer::OnDataAvailable
  10 0xbc0c306f
   9 nsCachedNetData::Release
   9 nsCacheManager::LimitDiskCacheSize
   9 libnecko.so
   9 libc.so.6
   9 GKLAYOUT.DLL
   8 nsHeaderEntry::nsHeaderEntry
   8 FindConstructor
   7 ntdll.dll
   7 nsGenericElement::GetBindingParent
   7 nsCOMPtr_base::~nsCOMPtr_base
   7 libpthread.so.0
   7 libgklayout.so
   7 js_MarkGCThing
   7 js_AllocGCThing
   7 gc_find_flags
   6 nsMsgKeySet::AddRange
   6 nsCSSFrameConstructor::CantRenderReplacedElement
   6 libmsgnews.so

Assignee

Comment 5

•

24 years ago

Could this be a dup of joki's bug 31847?  What's the source that adds the event
listener or sets the event handler that's firing?

/be

R.K.Aa.

Comment 6

•

24 years ago

Doubt it's a dup of 31847. Looks more like recent regression.
On linux 2001022721 i crash each time i double-click a link in sidebar history.

R.K.Aa.

Comment 7

•

24 years ago

Attached file backtrace from trunk SEA 2001022721 — Details

Assignee

Comment 8

•

24 years ago

I mean by dup of 31847 that this bug is another manifestation of the underlying
failure to root the event handler.  It may be a new symptom; it may be exposed
due to some more recent change that acted as an "agent cause", but the root
cause is likely to be the same as the one reported in bug 31847.

/be

Keyser Sose

Comment 9

•

24 years ago

Seeing this on Windows 98/2000 as well Heres the info:

Steps to reproduce:
1) Close and restart Mozilla (important wont work otherwise)
2) go to www.tweakers.net
3) Click a link under the "Tech Forums" section

JS_GetFunctionObject   [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3450]
nsScriptSecurityManager::GetFunctionObjectPrincipal
[d:\builds\seamonkey\mozilla\caps\src\nsScriptSecurityManager.cpp, line 906]   
     nsScriptSecurityManager::CheckFunctionAccess  
[d:\builds\seamonkey\mozilla\caps\src\nsScriptSecurityManager.cpp, line 614]   
     nsJSContext::CallEventHandler  
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 936]       
 nsJSDOMEventListener::HandleEvent  
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSDOMEventListener.cpp, line 92] 
       nsEventListenerManager::HandleEventSubType  
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
839]         nsEventListenerManager::HandleEvent  
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1422]         GlobalWindowImpl::HandleDOMEvent  
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 575]        
DocumentViewerImpl::LoadComplete  
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 717]  
      nsDocShell::EndPageLoad  
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2655]        
nsWebShell::EndPageLoad  
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 992]        
nsDocShell::OnStateChange  
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2573]        
nsWebShell::OnStateChange  
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 954]        
nsDocLoaderImpl::FireOnStateChange  
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 1309]        
nsDocLoaderImpl::doStopDocumentLoad  
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 736]        
0x01409010             nsDocLoaderImpl::DocLoaderIsEmpty  
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 637]        
nsDocLoaderImpl::OnStopRequest  
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 564]        
nsLoadGroup::RemoveRequest  
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 525]       
 nsStreamIOChannel::OnStopRequest  
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsInputStreamChannel.cpp, line
476]         nsOnStopRequestEvent::HandleEvent  
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamObserverProxy.cpp, line
179]         nsStreamObserverEvent::HandlePLEvent  
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamObserverProxy.cpp, line
79]         PL_HandleEvent  
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 577]        
_md_EventReceiverProc   [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 1055]         0x778b0c24

Keywords: topcrash

OS: Linux → All

Hardware: PC → All

Keyser Sose

Comment 10

•

24 years ago

*** Bug 70527 has been marked as a duplicate of this bug. ***

Comment 11

•

24 years ago

*** Bug 70781 has been marked as a duplicate of this bug. ***

Comment 12

•

23 years ago

Brendan, could I get your help in debugging this? Seems to be happening a lot,
but most often through caps. Is there a bad call in caps that's causing this, or
do you think it's a problem in the engine?

Assignee

Comment 13

•

23 years ago

I keep pointing to bug 31847, and I mean it.  This is not an engine bug.  It's
not a bug in mstoltz's code on the stack just below JS_GetFunctionObject, I bet.
It very likely arose due to a source code change in the XUL/JS that define and
add the handler, which would be implicated deeper on the stack.

The latest stack shows an onload handler being fired, I think.  What is the URI
of the document loaded in that docshell?  What is its onload handler or load
event listener?

/be

Comment 14

•

23 years ago

Despite the fact that this is out top crasher, I can't seem to reproduce it on
either Windows or Linux in this morning's build. Any clue as to what I'm
missing? Does it only happen in optimized builds, or only with certain skins?
Let's try to narrow down the conditions under which this crash occurs.

Status: NEW → ASSIGNED

Asa Dotzler [:asa]

Comment 15

•

23 years ago

I can repro this consistently with the steps at bug 71092 (if that's a
duplicate).  Just hit Ctrl N about 5 times pretty quickly and it should crash
for you

Comment 16

•

23 years ago

*** Bug 71092 has been marked as a duplicate of this bug. ***

Jay Patel [:jay]

Comment 17

•

23 years ago

This is also a topcrash for milestone .8.  Adding M08 and [@
JS_GetFunctionObject] [@ JS_GetPrivate] in summary for tracking. This is
currently the #3 crasher on the Trunk.  Here are some user comments and urls to
help find a reproducible test case:

26879486)
Comments: opened a new window and at the same time as window loaded I tried to
click the throbber icon (to go to mozilla.org)
     (26879498)	Comments: Opened a new window while closing another window
     (26880232)	Comments: clicked in history panel to open a new window
     (26919013)	URL: http://www.bonsai.com/ (26919013)	Comments: When I applied a new them (Blue to
Modern) I tried to open a new window because the current one doesn't work. File
Menu didn't work so I went  to about: and right clicked on Open In A New Window
when on the Mozilla 0.9 link. Somehow triggered a crash onceJS_GetFunctionObject
d0eadcdc
     (26934710)	URL: www.openoffice.org (26934981)	URL: www.boursorama.com (26934981)	Comments: Opening many new
links in new windows.
     (26949424)	Comments: i opened a lot of windows
     (26960863)	Comments: right-clicked on a link and picked "Open Link in new Window" then
I crashed upon opening of the new window.
     (26967127)	URL: www.donationjunction.com/www.ecologyfund.com/{some other site}
     (26987043)	URL: http://www.radonlabs.de (26987043)	Comments: Clicked on a thumbnail image.
     (26989949)	URL: http://www.mozillazine.org/build_comments/ (26990002)	URL:
http://www.mozillazine.org/build_comments/ (26990011)	URL:
http://www.mozillazine.org/build_comments/ (27009385)	Comments: After NS6 shutdown I got an
illegal operation crash.  Restart gives the same dialog.
     (27015731)	URL: http://www.slashdot.org (27015731)	Comments: Launching a link in a new window from
a Slashdot post
     (27043708)	URL: http://slahshdot.org/ (27043708)	Comments: Tried to open my profile on another
window. There was a ftp download from going on in the background.
     (27050591)	URL: http://astrology.yahoo.com/us/astrology/today/capricorntechscope.html (27065802)
URL: http://www.slashdot.org (27065802)	Comments: Launching a new browser window using Ctrl-N
     (27072376)	Comments: mail + web sites
     (27077741)	URL: http://www.anandtech.com (27077741)	Comments: Clicking a link to open a new window
     (27085520)	URL: http://www.afterforever.com (27085520)	Comments: Checking out the photogallery on
afterforever.com
     (27085932)	Comments: Opened a new browser window while checking email
     (27119609)	Comments: Tried to open a new Browser Window
     (27128818)	Comments: open new browser window from mail compose
     (27130285)	Comments: i was searching on google
     (27144729)	Comments: Opening the cygnus build tools for windows in a new window.  Also
downloading the source code for mozilla
     (27154579)	URL: www.flashpoint1985.com (27156159)	URL: http://www.brw.com.au/stories/20010223/8932.asp
(27157533)	URL: www.kurier.at (27157533)	Comments: when clicking on the "Printausgabe" link mozilla crashed
     (27157998)	URL: http://www.mozilla.org/quality/help/bugzilla-helper.html (27171277)	URL:
www.python.org/...
     (27171277)	Comments: start up
     (27176879)	Comments: Attempting to open a blank web page from the toolbar at the bottom
of the mail window.  No web page was open.
     (27185372)	URL: http://www.google.com (27191898)	URL: http://www.google.com (27197635)	URL:
http://commerce.us.dell.com/dellstore/config.asp?customer_id=04&keycode=6W473&order_code=891224u
(27210180)
Comments: Opening a few links in a new window without waiting for them to really
open.
     (27214553)	URL: http://bugzilla.mozilla.org/show_bug.cgi?id=70572 (27224964)	Comments: Programming
the chrome. I was loading a new navigator window with xul cache off.
     (27251227)	URL: www.thelandminesite.com (27255091)	URL: www.cyberpresse.ca (27255091)	Comments: Opening a link
in a new window; about four windows were already opened. Link was to same site.
     (27256756)	URL: www.cyberpresse.ca (27267059)	Comments: Crash on program exit

Summary: SEGV in JS_GetFunctionObject() on submission from Bugzilla Helper. → SEGV in [@ JS_GetFunctionObject] on submission from Bugzilla Helper. & M08 [@ JS_GetPrivate]

Asa Dotzler [:asa]

Comment 18

•

23 years ago

*** Bug 71254 has been marked as a duplicate of this bug. ***

Comment 19

•

23 years ago

Brendan, this doesn't look like a dup of 31877 to me. 31847 is crashing in
js_LockScope1, and this one's crashing in js_GetFunctionObject. Do you still
think they have the same cause?

Assignee

Comment 20

•

23 years ago

Never judge a crash by the victim frame at the top of the stack.

Yes, I still think this is a dup of 31847, which can crash the JS engine in many
places, by passing in a dead (garbage-collected, possibly even recycled as
another JS gc-thing, or even via the malloc heap) function object.

/be

Comment 21

•

23 years ago

Attached patch Brendan's patch - stops the crash but may leak — Details — Splinter Review

Comment 22

•

23 years ago

Giving the JSDOMEventListener a strong (rooted) reference to the event handler
function object stops the crash from happening, but it might leak.

Comment 23

•

23 years ago

Reassigning to Brendan.

Assignee: mstoltz → brendan

Status: ASSIGNED → NEW

Comment 24

•

23 years ago

Setting milestone to Moz0.9.

Target Milestone: --- → mozilla0.9

Assignee

Comment 25

•

23 years ago

So this is a dup of 31847.  I'll attach a revised patch there and leave it to
joki to bless it and check it in.

/be

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

Status: NEW → RESOLVED

Closed: 23 years ago

Resolution: --- → DUPLICATE