704245 - GUI hangs during network operations

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Yuri]

User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111117184314

Steps to reproduce:

I keep noticing this in 8.0 on FreeBSD: status message says "Transferring data from ..." and tabs can't be switched or scroll bars can't be scrolled until this data transfer is finished.

This behavior is very wrong and takes away from the user experience.

FF should act as a state machine with short state switches, network transfer should be processed only when finished (in select syscall style) since GUI at least in UNIX-like systems is socket-based and can be incorporated in the same waiting loop.

Comment 1

[Yuri]

I am setting importance to major since this bug significantly worsens user experience, causes firefox to look slower than it should be.

Comment 2

[Phoenix]

1) Same issue - Bug 591782?
2) Set javascript.options.mem.log to true, and check in Error Console what is you CC and GC times when hang

Comment 3

[Wayne Mery (:wsmwk)]

Yuri, what were you ablle to find?

(In reply to Phoenix from comment #2)
> 1) Same issue - Bug 591782?
> 2) Set javascript.options.mem.log to true, and check in Error Console what
> is you CC and GC times when hang

Comment 4

[Yuri]

I profiled and discussed this issue with the FreeBSD port maintainer.
After I reported the stack when chromium GUI was getting stuck, maintainer immediately fixed the issue (on FreeBSD) and since then this issue disappeared for me.

Please see the stack that lead to the fix below (for the record).
And this PR can be closed (as far as I am concerned).


----------------- thread 100213 (running) -----------------
 0x2ff820cb __sys_poll (f4309b0, 9, 5, 2ed2b32c, 5, 2ed2b32c) + 7
 0x2eca925b g_poll (f4309b0, 9, 5, f4309b0, 9, 2ed2b718) + 2b
 0x2ec9c2ed _init (edbe8a0, 0, 2fedf9c0, ecf1d78, 0, bfbfea28) + 315b9
 0x2ec9c8f5 g_main_context_iteration (edca300, 1, bfbfe238, ed13aa4, 0, ecf1d78) + 65
 0x8ece71c _ZN4base15MessagePumpGlib17RunWithDispatcherEPNS_11MessagePump8DelegateEPNS_21MessagePumpDispatcherE (edc5630, edcd100, 0, ecf1d78, ee839b0, ecf1d78) + 15a
 0x8eceaa7 _ZN4base15MessagePumpGlib3RunEPNS_11MessagePump8DelegateE (edc5630, edcd100, b787cf3, 8e698af, ed13898, edc3a0c) + 27
 0x8e67ed7 _ZN11MessageLoop11RunInternalEv (edcd100, ecf1d78, bfbfe478, 8eb4be9, ed13a9c, ed13a9c) + 12f
 0x8e67da5 _ZN11MessageLoop10RunHandlerEv (edcd100, edcd100, bfbfe4b8, 8e44401, b7850d8, 274) + 11
 0x8e68f1e _ZN16MessageLoopForUI17RunWithDispatcherEPN4base21MessagePumpDispatcherE (edcd100, 0, 1, 42, ecf1d78, ecf1d78) + 32
 0x8b6838a _ZN22ChromeBrowserMainParts18MainMessageLoopRunEPi (edc0150, edc441c, 0, d15281d, 2fe92ff4, 1) + 4c
 0xac094ca _ZN7content15BrowserMainLoop23RunMainMessageLoopPartsEPb (edc4410, ed24384, bfbfe6f7, d152340, 2fe95fd0, ecc4a30) + 384
 0xac07ec4 _Z11BrowserMainRKN7content18MainFunctionParamsE (bfbfe848, b7780c3, 0, 0, 0, 0) + 187
 0x8e0d4ac _ZN12_GLOBAL__N_123RunNamedProcessTypeMainERKSsRKN7content18MainFunctionParamsEPNS2_19ContentMainDelegateE (bfbfe850, bfbfe848, bfbfe984, ecf1d78, 0, 0) + 4e
 0x8e0da06 _ZN7content11ContentMainEiPPKcPNS_19ContentMainDelegateE (1, bfbfea20, bfbfe984, 8083ba1, ed0d50c, ebfcb08) + 449
 0x807603d ChromeMain (1, bfbfea20, bfbfe9c8, b6338bb, 30c0, bfbfea20) + 37
 0x8075fdb main (1, bfbfea20, bfbfea28, bfbfea00, bfbfea1c, 0) + 27
 0x8075f17 _start1 (2ea551d0, 1, bfbfea20, 0, 0, 0) + 87
 0x8075e88 _start (bfbfeb68, 0, bfbfeb6f, bfbfeb93, bfbfebda, bfbfebe7) + 18

Comment 5

[Yuri]

This was FreeBSD specific and was fixed in FreeBSD code by the porter.