Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 May 2014 19:30:00 GMT
From:      John Suykerbuyk <John@Suykerbuyk.org>
To:        chromium@FreeBSD.org
Subject:   Re: ports/186352: www/chromium 32.0.1700.102 hangs and becomes unresponsive.
Message-ID:  <201405151930.s4FJU0Xj051611@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/186352; it has been noted by GNATS.

From: John Suykerbuyk <John@Suykerbuyk.org>
To: bug-followup@FreeBSD.org, jjr@alisa.org
Cc:  
Subject: Re: ports/186352: www/chromium 32.0.1700.102 hangs and becomes unresponsive.
Date: Thu, 15 May 2014 13:22:15 -0600

 I was seeing the same issue on Chromium 32, built and installed from 
 ports  34.0.1847.132 (265804) and still have the same problem.
 
 Running PCBSD with the following uname info:
 FreeBSD t500 10-STABLE-p7 FreeBSD 10-STABLE-p7 #3 2bfa6cd(stable/10): 
 Fri Jan  3 15:35:35 EST 2014
 
 Many of the problems "feel" like the issues related to 
 "kern.ipc.shm_allow_removed=1" when Chrome 24 came out in 2013.  I have 
 confirmed that I am running with all the recommended shared memory 
 settings (see list below).
 
 In particular, reopening Chrome with several tabs (>7 or 8) usually 
 results in at least one page dieing for having run out of memory.  
 Hitting reload brings the page back.  Also on sites like facebook and 
 Google+, Google Calendar, text entry becomes INCREDIBLY slow and 
 delayed, often times with the "unresponsive page" dialog popping up to 
 kill it.  Closing and reopening the page "fixes" it for a very brief while.
 
 I see nothing in var/log or dmesg that indicates a problem, nor have I 
 (probably due to ignorance) seen anything in Chrome's task manager or 
 JavaScript console that could be used to identify the problem.
 
 
 I've had no similar issues with Firefox.
 - John "S"
 
 sysctl -a | grep kern.ipc
 
 kern.ipc.maxsockbuf: 2097152
 kern.ipc.sockbuf_waste_factor: 8
 kern.ipc.max_linkhdr: 40
 kern.ipc.max_protohdr: 60
 kern.ipc.max_hdr: 100
 kern.ipc.max_datalen: 68
 kern.ipc.maxmbufmem: 3056840704
 kern.ipc.nmbclusters: 373150
 kern.ipc.nmbjumbop: 186574
 kern.ipc.nmbjumbo9: 165843
 kern.ipc.nmbjumbo16: 124380
 kern.ipc.nmbufs: 2388165
 kern.ipc.maxpipekva: 98492416
 kern.ipc.pipekva: 2134016
 kern.ipc.pipefragretry: 0
 kern.ipc.pipeallocfail: 0
 kern.ipc.piperesizefail: 0
 kern.ipc.piperesizeallowed: 1
 kern.ipc.msgmax: 16384
 kern.ipc.msgmni: 40
 kern.ipc.msgmnb: 2048
 kern.ipc.msgtql: 40
 kern.ipc.msgssz: 8
 kern.ipc.msgseg: 2048
 kern.ipc.semmni: 50
 kern.ipc.semmns: 340
 kern.ipc.semmnu: 150
 kern.ipc.semmsl: 340
 kern.ipc.semopm: 100
 kern.ipc.semume: 50
 kern.ipc.semusz: 632
 kern.ipc.semvmx: 32767
 kern.ipc.semaem: 16384
 kern.ipc.shmmax: 536870912
 kern.ipc.shmmin: 1
 kern.ipc.shmmni: 1024
 kern.ipc.shmseg: 1024
 kern.ipc.shmall: 131072
 kern.ipc.shm_use_phys: 0
 kern.ipc.shm_allow_removed: 1
 kern.ipc.soacceptqueue: 128
 kern.ipc.numopensockets: 354
 kern.ipc.maxsockets: 192375
 kern.ipc.sendfile.readahead: 1
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405151930.s4FJU0Xj051611>