Closed Bug 584057 Opened 14 years ago Closed 14 years ago

Firefox hangs after detaching the second tab by dropping it onto the desktop

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta3+

People

(Reporter: ahoza, Assigned: igor)

References

Details

(Keywords: hang, regression, Whiteboard: [4b3])

Attachments

(2 files)

Attached image Screenshot
Environment:
OS: Win7(32)
BuildID: Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3pre) Gecko/20100803 Minefield/4.0b3pre

Steps to reproduce:

1. Create a new profile.
1. Visit cnn.com.
2. Open 3-4 links from that page in new tabs.
3. Detach a tab by dropping it onto the desktop.
4. Detach a second tab by dropping it onto the desktop.

Expected results:
Tab drop should open a new window with the contents of the tab after steps 3 and 4.

Actual results:
After step 4, FF hangs.

Notes: Also occurred with nypost.com (but not all the time like with cnn.com)  
Flash plugin is up to date (not sure if this is relevant)
Verified this in Safe Mode and the behavior is the same.
I am able to reproduce this Issue with Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3pre) Gecko/20100803 Minefield/4.0b3pre ID:20100803055502.

This isn't a Plugin Issue since it's reproduceable in Safe-Mode + disabling any Plugins.

It's Reproducable turning the HTML5 Parser, IPC and JIT Content on/off.

There's no hang if i block Loading any Access to "http://svcs.cnn.com/weather/_getforecast?".

Attaching a WinDbg Log. Timeless, mind having a Look at it if it's usefull at all?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Found a Regression Range on MC-Repo using Hourly Builds:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0f6f1e759cd1&tochange=e9c9b7d21a0c what points to a big TM -> MC Merge.
Hunting on TM-Branch now.

Correction to Comment 1:
There's no hang if i block Access to "http://svcs.cnn.com/weather/getforecast?" using a suitable Adblocker.
Assignee: nobody → general
Component: General → JavaScript Engine
Keywords: regression
QA Contact: general → general
Found a Regression Range on TM-Branch now:
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=4de031f4788f&tochange=9539f400bb58
Cannot narrow down any further cause there are missing Win32 Build on http://hourly-archive.localgho.st/hourly-archive2/tracemonkey-win32/ probably due to Build Failures.
blocking2.0: --- → ?
Reproducible on Mac 10.6 and Linux 10.04 as well. Changing platform and OS.
OS: Windows 7 → All
Hardware: x86 → All
Blocking issue for Firefox 4b3, I think.
Rob, can you take a look?
Easily reproducible, doesn't matter if you start with cnn.com - any three tabs will do, clear hang the second time you detach a tab.

On OSX, Shark says (15s, only 2 samples collected):

50.0%	50.0%	mach_kernel	lck_mtx_lock
0.0%	50.0%	mach_kernel	 ipc_object_translate
0.0%	50.0%	mach_kernel	  port_name_to_semaphore
0.0%	50.0%	mach_kernel	   semaphore_timedwait_signal_trap_internal
0.0%	50.0%	mach_kernel	    __semwait_signal_nocancel
0.0%	50.0%	mach_kernel	     unix_syscall
50.0%	50.0%	libmozjs.dylib	js_NextActiveContext(JSRuntime*, JSContext*)
0.0%	50.0%	XUL	 XPCJSRuntime::WatchdogMain(void*)
0.0%	50.0%	libnspr4.dylib	  _pt_root
0.0%	50.0%	libSystem.B.dylib	   _pthread_start
0.0%	50.0%	libSystem.B.dylib	    thread_start

and gdb says:

#0  0x90909066 in __semwait_signal ()
#1  0x90908d22 in _pthread_cond_wait ()
#2  0x9090a9b8 in pthread_cond_wait$UNIX2003 ()
#3  0x02673ef1 in PR_WaitCondVar ()
#4  0x0241b989 in BeginGCSession ()
#5  0x0241b9f4 in js::SetProtoCheckingForCycles ()
#6  0x02444b2d in js::SetProto ()
#7  0x02446bfb in obj_setProto ()
#8  0x0244c3e0 in js_SetPropertyHelper ()
#9  0x0243105e in js::Interpret ()
#10 0x024357bb in js::Execute ()
#11 0x023d12a8 in JS_ExecuteScript ()
#12 0x0058edaf in nsJSContext::ExecuteScript ()
#13 0x00570da1 in nsXULDocument::ExecuteScript ()
#14 0x00577171 in nsXULDocument::OnStreamComplete ()
#15 0x0004dafa in nsStreamLoader::OnStopRequest ()
#16 0x000f67cc in nsJARChannel::OnStopRequest ()
#17 0x00030b40 in nsInputStreamPump::OnStateStop ()
#18 0x000311b8 in nsInputStreamPump::OnInputStreamReady ()
#19 0x00d00e74 in nsInputStreamReadyEvent::Run ()
#20 0x00d196dc in nsThread::ProcessNextEvent ()
#21 0x00cd8e77 in NS_ProcessPendingEvents_P ()
#22 0x00bf10e2 in nsBaseAppShell::NativeEventCallback ()
#23 0x00bb40e8 in nsAppShell::ProcessGeckoEvents ()
#24 0x98dab0fb in __CFRunLoopDoSources0 ()
#25 0x98da8bbf in __CFRunLoopRun ()
#26 0x98da8094 in CFRunLoopRunSpecific ()
#27 0x98da7ec1 in CFRunLoopRunInMode ()
#28 0x93590f9c in RunCurrentEventLoopInMode ()
#29 0x93590c8d in ReceiveNextEventCommon ()
#30 0x93590bd6 in BlockUntilNextEventMatchingListInMode ()
#31 0x96dbea89 in _DPSNextEvent ()
#32 0x96dbe2ca in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#33 0x96d8055b in -[NSApplication run] ()
#34 0x00bb371a in nsAppShell::Run ()
#35 0x00a2f727 in nsAppStartup::Run ()
#36 0x0000ecb7 in XRE_main ()
#37 0x00001d48 in main ()
Whiteboard: [4b3]
this might be fixed by bug 583777. investigating.
Assignee: general → igor
Igor could you look at this? I'm still tripping the 

Assertion failure: !cx->prevRequestContext, at /Users/sayrer/dev/mozilla-central/js/src/jsapi.cpp:776

with the patch for bug 583777 applied.
Igor, is this related to bug 584673 ??
Found Igor on IRC. he's looking at this right now.
(In reply to comment #8)
> Easily reproducible, doesn't matter if you start with cnn.com - any three tabs
> will do, clear hang the second time you detach a tab.

This is in an optimized build?
We think that this is probably just one way to exercise the problematic code, so this will require a b3 respin.
blocking2.0: ? → beta3+
I think this is a dup of bug 584551. My debug build points to that but lets keep this open until we can verify.
Depends on: 584551
(In reply to comment #13)
> (In reply to comment #8)
> > Easily reproducible, doesn't matter if you start with cnn.com - any three tabs
> > will do, clear hang the second time you detach a tab.
> 
> This is in an optimized build?

It's a nightly, so yes, optimized.
No longer depends on: 584551
bug 584551 just landed on m-c.
Fixed by bug 584551, I just verified it using the Tinderbox hourlies (I did have trouble dragging tabs to the desktop, but that was during session restore, and I think that's a separate issue)

I'd be thrilled if someone else could verify; here are hourly builds that have the fix:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx/1281044249/
and
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux/1281043944/

(no windows yet)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Well, now this should be in a nightly.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: