Closed Bug 270721 Opened 20 years ago Closed 20 years ago

stack overflow [@ js_SearchScope]

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.8beta2

People

(Reporter: timeless, Assigned: brendan)

Details

(Keywords: crash, js1.5, topcrash)

Crash Data

Attachments

(1 file)

aviary 1.0.1 branch patch to catch recursion with an assert
928 bytes, patch
Details | Diff | Splinter Review 
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=js_SearchScope&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

407 crashes found where the Stack Signature contains 'js_searchscope' and the
sort is by ID.

Incident ID: 2036141
Stack Signature	js_SearchScope 9a57b9c9
Product ID	Firefox10
 Build ID	2004080301

Incident ID: 2034516
Stack Signature	js_SearchScope 6786c7e7
Product ID	Firefox10
Build ID	200410010

Incident ID: 2034516
Stack Signature	js_SearchScope 6786c7e7
Product ID	Firefox10
Build ID	2004100109
URL visited	http://www.google.com

Incident ID: 2033856
Stack Signature	js_SearchScope 6786c7e7
Product ID	Firefox10
Build ID	2004110711
URL visited	http://www.okcupid.com

Incident ID: 2024609
Stack Signature	js_SearchScope 6786c7e7
Product ID	Firefox10
Build ID	2004110711
Trigger Time	2004-11-17 20:13:26.0
URL visited	
User Comments	I don't know really. I was playing mp3's at the time in foobar2000
if that helps. That was the only other application running. It occured right
after starting up and attempting to go to www.sourceforge.net

and of course, my crash which is no more useful :)

Incident ID: 2038310
Stack Signature	js_SearchScope 6786c7e7
Product ID	MozillaTrunk
Build ID	2004110805
Trigger Time	2004-11-18 12:14:18.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0003b797)
URL visited	google (?)
User Comments	searching for alps touchpad windows -linux
Since Last Crash	836177 sec
Total Uptime	837853 sec
Trigger Reason	Stack overflow
Source File, Line No.
c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsscope.c,
line 250
Stack Trace 	
js_SearchScope 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsscope.c,
line 250]
js_LookupPropertyWithFlags 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2361]
js_LookupProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2328]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2608]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
js_GetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2667]
Line numbers don't make sense in the inline stack trace -- what's going on here,
can someone trace the control flow using accurate trunk or aviary-branch linenos?

/be
I seem to have encountered the same crash .

I am doing some primative automated stress testing on MSWin XP Home Ed , and
unfortunately I do not know how to recreate .  This is the 1st time I have seen
this crash .

I am using the Firefox 1.0.0 code base , and it is a debug build .

JS3250.DLL : 0xC00000FD: Stack Overflow

js_SearchScope(JSScope * 0x037f1d98, long 58683744, int 0) line 261 + 26 bytes
js_LookupPropertyWithFlags(JSContext * 0x00dd5378, JSObject * 0x038005f0, long
58683744, unsigned int 0, JSObject * * 0x00043158, JSProperty * * 0x0004314c,
const char * 0x100d6fb4, unsigned int 2693) line 2429 + 15 bytes
_js_LookupProperty(JSContext * 0x00dd5378, JSObject * 0x038005f0, long 58683744,
JSObject * * 0x00043158, JSProperty * * 0x0004314c, const char * 0x100d6fb4,
unsigned int 2693) line 2580 + 35 bytes
js_GetProperty(JSContext * 0x00dd5378, JSObject * 0x038005f0, long 58683744,
long * 0x0012c5c8) line 2693 + 35 bytes
js_GetProperty(JSContext * 0x00dd5378, JSObject * 0x038005f0, long 58683744,
long * 0x0012c5c8) line 2747 + 27 bytes
<< pruned ~1000 identical repeats on the stack of these entries >>
js_GetProperty(JSContext * 0x00dd5378, JSObject * 0x038005f0, long 58683744,
long * 0x0012c5c8) line 2747 + 27 bytes
js_GetProperty(JSContext * 0x00dd5378, JSObject * 0x038005f0, long 58683744,
long * 0x0012c5c8) line 2747 + 27 bytes
js_GetProperty(JSContext * 0x00dd5378, JSObject * 0x038005f0, long 58683744,
long * 0x0012c5c8) line 2747 + 27 bytes

--

\js\src\jsscope.c , ln 261 

    /* Compute the primary hash address. */
->  hash0 = SCOPE_HASH0(id);
    hashShift = scope->hashShift;
    hash1 = SCOPE_HASH1(hash0, hashShift);
    spp = scope->table + hash1;
With a stack overflow, the leaf frame where the pc was last before the OS killed
the thread is not interesting.  The nested calls and the logic governing them is
the key.  Here, it looks like some object appears to be non-native, yet uses
js_GetProperty as its JSObjectOps.getProperty hook.

Lloyd, thanks for the good line numbers.  If you still happen (I can hope!) to
have this in the debugger, or can (unlikely, hope springs eternal) reproduce it,
when you go up to the next-to-top-most js_GetProperty call (the one at line 2747
in jsobj.c), can you evaluate this expression:

((JSClass*)(obj2->slots[2]-1))->name

and report back?  Thanks,

/be
Assignee: general → brendan
Keywords: js1.5
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta2
This should apply to any jsobj.c, I think.  It asserts before the recursion
point that obj2->map->ops->getProperty != js_GetProperty.  Lloyd, I hope you
can give this a try.

/be
Hi Brendan ,

Thank you for the timely response !

I still have the environment up , in response to 2005-02-27 09:30 PST :
-	obj2	0x038005f0
   -	map	0x037f1d98
	nrefs	1
      -	ops	0x02f9dac8 XPC_WN_NoCall_JSOps
	newObjectMap	0x10001c12 _js_NewObjectMap
	destroyObjectMap	0x100013d4 _js_DestroyObjectMap
	lookupProperty	0x10001843 __js_LookupProperty
	defineProperty	0x10001406 _js_DefineProperty
	getProperty	0x10001320 _js_GetProperty
	setProperty	0x10001947 _js_SetProperty
	getAttributes	0x10001091 _js_GetAttributes
	setAttributes	0x1000100f _js_SetAttributes
	deleteProperty	0x10001285 _js_DeleteProperty
	defaultValue	0x100016b3 _js_DefaultValue
	enumerate	0x02f5f7c0 XPC_WN_JSOp_Enumerate(JSContext *, JSObject *,
JSIterateOp, long *, long *)
	checkAccess	0x10001915 _js_CheckAccess
	thisObject	0x00000000
	dropProperty	0x100011b8 _js_DropProperty
	call	0x00000000
	construct	0x00000000
	xdrObject	0x00000000
	hasInstance	0x10001613 _js_HasInstance
	setProto	0x10001bd6 _js_SetProtoOrParent
	setParent	0x10001bd6 _js_SetProtoOrParent
	mark	0x10001992 _js_Mark
	clear	0x10001d02 _js_Clear
	getRequiredSlot	0x100016d1 _js_GetRequiredSlot
	setRequiredSlot	0x10001037 _js_SetRequiredSlot
	nslots	1065
	freeslot	838
   -	slots	0x03e7761c
		58721768
+	sprop	0x038ef2d4

----

When I get a chance I will apply the patch to get more diagnostic data .
I have a sinking feeling that the MAP_IS_NATIVE test in jsobj.h doesn't work
across DLL boundaries:

/* Test whether a map or object is native. */
#define MAP_IS_NATIVE(map)                                                    \
    ((map)->ops == &js_ObjectOps ||                                           \
     ((map)->ops && (map)->ops->newObjectMap == js_ObjectOps.newObjectMap))

We know from comment 5 (thanks, Lloyd) that the ops at hand here,
XPC_WN_NoCall_JSOps, has a newObjectMap hook referencing _js_NewObjectMap, which
should be the same function pointer as js_ObjectOps.newObjectMap (note that
xpconnect copies js_ObjectOps over XPC_WN_NoCall_JSOps and then specializes only
the enumerate hook).

So, for debug Firefox builds where DLLs are used, and for the suite (which
always uses DLLs, debug or optimized), for this recursion path to be taken, the
object must appear non-native, yet have a map->ops->getProperty referencing
js_GetProperty.

Is there a thunk or PIC-ish relocation helper of some sort at work here?  If so,
why does it affect Firefox (from talkback), or could those Firefox build ids in
comment 0 all be from debug builds?

/be
And if xpconnect really memcpy's or struct-assigns js_ObjectOps onto
XPC_WN_NoCall_JSOps, then the newObjectMap member ought to point to the
DLL-internal function entry point, anyway.

Baffling.  Why does js_GetProperty call itself here if the object has
XPC_WN_NoCall_JSOps as its object-ops?

/be
Status: NEW → ASSIGNED
generally speaking debug builds and talkback builds are non intersecting sets.
AFAIK for XPConnect or any DLL for that matter to have a different address for
_js_NewObjectMap than the JS DLL the executable and XPConnect would have to be
using different versions, debug/release. But in our builds the DLL's are named
the same, so that's unlikely.

So MAP_IS_NATIVE should be the preventor of recursion in this case?

If the ops had gotten corrupted, the debugger wouldn't have spit out the
function name, so that's probably not the issue.

I can't think of any other way to confuse this address test, unless you unloaded
and reloaded the DLL during the course of apps life.
Jay, is this still happening?  The stack doesn't make sense, as dbradley agrees
in comment 9.

/be
I have not seen a reoccurrence , but had only seen it that one time anyway .
There aren't any incidents with this stack signature in current Trunk Talkback data:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=js_SearchScope&vendor=All&product=FirefoxTrunk&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Marking this worksforme.  If anyone can reproduce this on the Trunk, feel free
to reopen (I doubt we're going to do anything about this on the Aviary branch).
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ js_SearchScope]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: