Closed Bug 455146 Opened 16 years ago Closed 16 years ago

TM: Going to NEW Facebook profile page causes crash. [@ FlushNativeStackFrame]

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1b1

People

(Reporter: snick525, Assigned: brendan)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(2 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913064101 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913064101 Minefield/3.1b1pre

Enabling the NEW version of Facebook, and then opening your own profile page, causes a crash with the Tracemoney build.

Reproducible: Always

Steps to Reproduce:
1.Log into Facebook
2.Enable the NEW layout.
3.Surf to Profile page.
Actual Results:  
The browser crashed, every time.

Expected Results:  
Loaded the page, and not crashed.Adblock Plus 0.7.5.5
Better Gmail 2 0.6.1
Locationbar² 1.0.3
Menu Editor 1.2.6
Nightly Tester Tools 2.0.2
NoScript 1.8
Tabs Open Relative 0.3.3
Topper 0.2
TwitterFox 1.7

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913064101 Minefield/3.1b1pre ID:20080913064101

Adblock Plus 0.7.5.5
Better Gmail 2 0.6.1
Locationbar² 1.0.3
Menu Editor 1.2.6
Nightly Tester Tools 2.0.2
NoScript 1.8
Tabs Open Relative 0.3.3
Topper 0.2
TwitterFox 1.7

Is my browser configuration.
http://crash-stats.mozilla.com/report/index/f9f1dbe1-81a9-11dd-a966-001cc45a2c28

Crashed for me with
  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080912031847 Minefield/3.1b1pre 
and
  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080913031911 Minefield/3.1b1pre

Couldn't get it to crash with a debug build.
Have you enabled TM ?
Please test with and without TM if you report a bug.

0  	js3250.dll  	FlushNativeStackFrame  	 js/src/jstracer.cpp:1249
1 	js3250.dll 	js_ExecuteTree 	js/src/jstracer.cpp:2454
2 	js3250.dll 	js_MonitorLoopEdge 	js/src/jstracer.cpp:2502
3 	js3250.dll 	js3250.dll@0x6963a 	
4 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1324
5 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523
6 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:565
7 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
8 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
9 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1080
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Summary: Going to NEW Facebook profile page causes crash. → Going to NEW Facebook profile page causes crash. [ @FlushNativeStackFrame]
I'll try to confirm once I get power enough to rebuild my Minefield. Feel free to beat me to it. (Walkabout in NYC atm.)

/be
Summary: Going to NEW Facebook profile page causes crash. [ @FlushNativeStackFrame] → TM: Going to NEW Facebook profile page causes crash. [ @FlushNativeStackFrame]
Also if anyone can capture the script (call js_Disassemble(cx, cx->fp->script, 0, stdout) (on Mac use __stdoutp; not sure about Windows) and pc (cx->fp->regs->pc) or line number (call js_PCToLineNumber(cx, cx->fp->script, cx->fp->regs->pc)) that would be great.

/be
I give it a try.
I can confirm the crash. I have to build a DEBUG version to catch it in gdb.
Status: UNCONFIRMED → NEW
Ever confirmed: true
With my current build, with JIT:Content enabled (JIT:Chrome has no effect), it will crash every time, even in safe mode.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913205356 Minefield/3.1b1pre ID:20080913205356


http://crash-stats.mozilla.com/report/index/c1c90028-8222-11dd-81fa-001a4bd43ef6
http://crash-stats.mozilla.com/report/index/1e8aedd9-8223-11dd-a0c3-001a4bd43e5c?p=1
Need an assignee -- I'm getting set up to debug, but probably some folks not on the road could grab and diagnose this faster. Andreas, did you get anywhere with it? No worries if not -- just want to keep after unassigned bugs.

/be
This happens on OS X too.
Assignee: general → danderson
FlushNativeStackFrame is clobbering cx->fp->regs to 0x16 (undefined).  We're filling in missing arguments at calldepth=1.  vpname=missing, vpnum=0, nargs=3, args=2.
Brendan tried digging into this for me today.  Looks like stack space is not being reserved correctly in synthesizing frames, something somewhere might not be compensating for the missing argument in the inner frame.
Assignee: danderson → brendan
Status: NEW → ASSIGNED
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1b1
Attached patch proposed fix (obsolete) — Splinter Review
Attachment #340020 - Attachment is obsolete: true
Attachment #340031 - Flags: review?(danderson)
Attached patch better fix (obsolete) — Splinter Review
Attachment #340031 - Attachment is obsolete: true
Attachment #340045 - Flags: review?(danderson)
Attachment #340031 - Flags: review?(danderson)
Attachment #340045 - Flags: review?(mrbkap)
Depends on: 453024
May do a followup bug and patch to share code with a jsinterp.h static inline helper, if it can be done without too many params.

/be
Attachment #340045 - Attachment is obsolete: true
Attachment #340109 - Flags: review?(danderson)
Attachment #340045 - Flags: review?(mrbkap)
Attachment #340045 - Flags: review?(danderson)
The unrelated bug is the assertion in js_GetScopeChain:

    if (!obj) {
        /*
         * Don't force a call object for a lightweight function call, but do
         * insist that there is a call object for a heavyweight function call.
         */     
        JS_ASSERT(!fp->fun ||       
                  !(fp->fun->flags & JSFUN_HEAVYWEIGHT) ||
                  fp->callobj);

botching because we do not js_GetCallObject when reconstructing a frame for a heavyweight function call that the JIT inlined. Filing that now as bug 456875.

/be
Attachment #340109 - Attachment is obsolete: true
Attachment #340223 - Flags: review?(mrbkap)
Attachment #340109 - Flags: review?(danderson)
Comment on attachment 340223 [details] [diff] [review]
fixed spot-fix, exposes unrelated bug

Bugzilla interdiff works. David, if could verify that this is the patch I wrote on your thinkpad that would be good for a second r+ -- thanks,

/be
Attachment #340223 - Flags: review?(danderson)
Attachment #340223 - Flags: review?(danderson) → review+
Attachment #340223 - Flags: review?(mrbkap) → review+
Fixed on m-c:

http://hg.mozilla.org/mozilla-central/rev/966828ea2d4d

/be
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Brendan, did you ever create a reduced testcase?  Would be nice not only for automated regression testing, but also to inform fuzzing efforts.
Firefox - 3.1b1pre  crashes everytime I login to new facebook.com 
The build id:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080929033431 Minefield/3.1b1pre

If I use a proxy like proxomitron, it doesn't crash. But crashes everytime without proxy.
(In reply to comment #23)
> Firefox - 3.1b1pre  crashes everytime I login to new facebook.com 
> The build id:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre)
> Gecko/20080929033431 Minefield/3.1b1pre
> 
> If I use a proxy like proxomitron, it doesn't crash. But crashes everytime
> without proxy.

Please file a new bug and cite breakpad crash report ids if you can. Thanks,

/be
Flags: in-testsuite-
Flags: in-litmus-
Keywords: crash
Summary: TM: Going to NEW Facebook profile page causes crash. [ @FlushNativeStackFrame] → TM: Going to NEW Facebook profile page causes crash. [@ FlushNativeStackFrame]
Crash Signature: [@ FlushNativeStackFrame]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: